On Wed, Aug 24, 2016 at 2:58 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> Now, for bigger segment sizes, I think there actually could be a
> little bit of a noticeable performance hit here, because it's not just
> about total elapsed time. Even if the code eventually touches all of
> the memory, it might not touch it all before starting to fire up
> workers or whatever else it wants to do with the DSM segment. But I'm
> thinking we still need to bite the bullet and pay the expense, because
> crash-and-restart cycles are *really* bad.
Here is a new rebased version of this patch, primarily to poke this
thread as an unresolved question. This patch is not committable as is
though: I discovered that parallel query can cause fallocate to return
with errno == EINTR. I haven't yet investigated whether fallocate is
supposed to be restartable, or signals should be blocked, or something
else is wrong. Another question is whether the call to ftruncate() is
actually necessary before the call to fallocate().
Unfounded speculation: fallocate() might actually *improve*
performance of DSM segments if your access pattern involves random
access (just to pick an example out of the air, something like...
building a hash table), since it's surely easier to allocate a big
contiguous chunk than a squillion random pages most of which divide an
existing hole into two smaller holes...
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
