Jeff Frost <jeff@pgexperts.com> writes:
> In our customer's case, the size of pg_attribute was a little less than 1/4 of shared_buffers, so might not be the
syncscan?
Could you go back and double check that? If the shared_buffers setting
were 7GB not 8GB, that would fall right between the pg_attribute sizes
you posted before. I'm getting somewhat convinced that this is the
right answer, because I've been able to reproduce an unexpectedly long
stall with multiple clients connecting simultaneously to an
init-file-less database whose pg_attribute is large enough to trigger
syncscans. The particular case I'm testing has pg_attribute of about
1GB (in a machine with just 4GB RAM, so I'm not going to push it up
much further). If I just remove the init file and connect with psql,
there's about a 1-second startup delay, which is bad enough; but if
I throw 50 concurrent connections at it with a hacked-up version of
pgbench, it takes about 45 seconds for all of them to get through
startup. (You need to hack pgbench to suppress the single
initialization connection it normally likes to make, else the test
degenerates to the one-incoming-connection case.)
I think that a big chunk of this is coming from the syncscan logic
defeating the early-exit optimization in RelationBuildTupleDesc;
but it still seems like there's another inefficiency somewhere.
Maybe our syncscan logic just really sucks given enough backends
trying to piggyback on the same syncscan. Now that I can reproduce it,
I'll take a closer look at that.
In the meantime, it looks like a trivial workaround is to disable
synchronize_seqscans via postgresql.conf.
regards, tom lane
