[development] Drupal performance patches: call for action

[Gerhard Killesreiter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dries Buytaert schrieb:
> 
> On 01 Aug 2007, at 11:37, Gerhard Killesreiter wrote:
>> Yeah, I'd be one of the people who have reservations on this, especially
>> on the node_counter part. This will give a lot of writes to the node
>> table, which is a stupid thing to do considering that the rest of the
>> table is -+ static (compared to the node counter table).
> 
> Here is the concise summary:
> 
>  1. Locality of information is important -- it avoids queries.  If you
> use A and B together, you want to get that data in one query.  This
> holds for both spatial and temporal locality.
> 
>  2. You want to split cold and hot data -- it avoids having to load
> large amounts of data into memory.
> 
> Sometimes, both are at odds -- especially when MySQL's locking comes
> into play.

I didn't even mention locking. :p
Also, Köhntopp mentions specifically InnoDB, not MyISAM, so I believe
his analysis doesn't only apply to MyISAM.

> In case of the user access table it might make sense to split of the
> access-field.  It's a "cold" field; it's hardly ever read but it does
> get some writes.

Right. Also the "login" field.

> Because the field is almost never read, the fact that
> we loose spatial locality isn't much of a concern.
> 
> The node_counter field is both read and write heavy.  By splitting it

If you use the feature, yes. There is good reason to not use it.

> off, you loose the locality advantage and it's not clear what is more
> important: the fact that we can simplify thousands of read queries, or
> the fact that we can avoid some table locking.  Only extensive
> benchmarks can tell.

Yeah, that sums it up neatly. Problem is: Nobody is going to do
benchmarks extensive enough to tell.

Cheers,
	Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGsGWGfg6TFvELooQRAsBlAKCsepQtOGsalhp8g4CIDDEEHxt4JACeM2FQ
ZBp5QILQxgK9ZaJIQNBHQag=
=iUvI
-----END PGP SIGNATURE-----