[...] If you make the sorting criterion include the tablespace id you wouldn't need the lookahead loop in NextBufferToWrite().

I'm considering this precise point, i.e. including the tablespace as
a sorting criterion.

Currently the array used for sorting is 16 bytes per buffer (although I wrote 12 in another mail, I was wrong...). The data include the bufid (4 bytes) the relation & fork num (8 bytes, but really 4 bytes + 2 bits are used), and the block number (4 bytes) which is the offset within the relation. These 3 combined data allow to find the file and the offset within that file, for the given buffer id.

I'm concerned that these 16 bytes are already significant and I do not want to extend them any more. I was already pretty happy with the previous version with 4 bytes per buffer.

Now as the number of tablespace is expected to be very small (1, 2, maybe 3), there is no problem to pack it within the unused 30 bits in forknum. That would mean some masking and casts here and there, so it would not be very beautiful, but it would make it easy to find the buffers for a given tablespace, and indeed remove the lookahead stuff in the next buffer function, as you suggest.

My question is: would that be acceptable, or would someone object to the use of masks and things like that? The benefit would be a simpler/more direct next buffer function, but some more tinkering around the sorting criterion to use a packed representation.

Note that I do not think that it would have any actual impact on performance... it would only make a difference if there were really many tablespaces (the scanning complexity would be Nbuffer instead of Nbuffer*Ntablespace, but as Ntablespace is small...). My motivation is rather to help the patch get through, so I'm fine if this is not needed.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to