On Fri, May 25, 2012 at 11:17 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Merlin Moncure (mmonc...@gmail.com) wrote: >> Right -- duh. Well, hm. Is this worth fixing? ISTM there's a bit of >> 'optimizing for pgbench-itis' in the buffer partitions -- they seem >> optimized to lever the mostly random access behavior of pgbench. But >> how likely is it to see multiple simultaneous scans in the real world? >> Interleaving scans like that is not a very effective optimization -- >> if it was me, it'd be trying to organize something around a >> partitioned tid scan for parallel sequential access. > > Didn't we implement a system whereby this is exactly what we intend to > happen on the read side- that is, everyone doing a SeqScan gangs up on > one ring buffer and follows it, which we felt was going to dramatically > improve performance in some cases?
yeah: /* * If the table is large relative to NBuffers, use a bulk-read access * strategy and enable synchronized scanning (see syncscan.c). Although * the thresholds for these features could be different, we make them the * same so that there are only two behaviors to tune rather than four. * (However, some callers need to be able to disable one or both of these * behaviors, independently of the size of the table; also there is a GUC * variable that can disable synchronized scanning.) * * During a rescan, don't make a new strategy object if we don't have to. */ if (!RelationUsesLocalBuffers(scan->rs_rd) && scan->rs_nblocks > NBuffers / 4) { allow_strat = scan->rs_allow_strat; allow_sync = scan->rs_allow_sync; } else allow_strat = allow_sync = false; if (allow_strat) { if (scan->rs_strategy == NULL) scan->rs_strategy = GetAccessStrategy(BAS_BULKREAD); } I wonder if the logic here is just being too strict... merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers