On Wed, 5 Aug 2009, Robert Haas wrote:
> On Wed, Aug 5, 2009 at 6:20 AM, Matthew Wakeling<matthew@flymine.org> wrote:
>> It is certainly doing a sequential scan. So are you saying that it will
>> start a sequential scan from a different part of the table each time, even
>> in the absence of other simultaneous sequential scans? Looks like I'm going
>> to have to remove the limit to get sensible results - I only added that to
>> make the query return in a sensible time for performance testing.
>>
>> Some trivial testing with "select * from location limit 10;" indicates that
>> it starts the sequential scan in the same place each time - but is this
>> different from the above query?
>
> Maybe it's because of this?
>
> http://www.postgresql.org/docs/8.3/static/runtime-config-compatible.html#GUC-SYNCHRONIZE-SEQSCANS
Thanks, we had already worked that one out. What I'm surprised about is
that it will start the sequential scan from a different part of the table
when there aren't any simultaneous scans, but not when I do the trivial
testing.
Having reduced the data quantity (so I can throw away the limit) makes my
tests produce much more consistent results. I label this problem as
solved. Thanks all.
Matthew
--
$ rm core
Segmentation Fault (core dumped)
