Hello Jim,
The small problem I see is that for a very large setting there could be
several seconds or even minutes of sorting, which may or may not be
desirable, so having some control on that seems a good idea.
ISTM a more elegant way to handle that would be to start off with a very
small number of buffers and sort larger and larger lists while the OS is busy
writing/syncing.
You really have to have done a significant part/most/all of sorting before
starting to write.
Another argument is that Tom said he wanted that:-)
Did he elaborate why? I don't see him on this thread (though I don't have all
of it).
http://www.postgresql.org/message-id/6599.1409421...@sss.pgh.pa.us
But it has more to do with memory management.
In practice the value can be set at a high value so that it is nearly
always sorted in one go. Maybe value "0" could be made special and used
to trigger this behavior systematically, and be the default.
It'd be nice if it was just self-tuning, with no GUC.
Hmmm. It can easilly be turned into a boolean, but otherwise I have no
clue about how to decide whether to sort and/or flush.
It looks like it'd be much better to get this committed without more than we
have now than to do without it though...
Yep, I think the figures are definitely encouraging.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
