Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> I may be confused, but why would the physical ordering of the table
>> entries make a difference to the correct answers for this test?
>> (I can certainly see why that might break the brin code, but not
>> why it should change the seqscan's answers.)
> We create the brintest using a scan of tenk1 LIMIT 100, without
> specifying the order. So whether we find rows that match each test query
> is pure chance.
Oooh ... normally that would not matter, but I wonder if what's happening
on chipmunk is that the synchronized-seqscan logic kicks in and causes us
to read some other part of tenk1 than we normally would, as a consequence
of some concurrent activity or other. The connection to smaller than
normal shared_buffers would be that it would change our idea of what's a
large enough table to justify using synchronized seqscans.
Peter's patch failed to hit the place where this matters, btw.
regards, tom lane