Jeff Frost <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers