Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

On Fri, May 25, 2012 at 11:17 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Merlin Moncure (mmoncure@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