Hello,
[...] 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.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
