On Wed, 5 Aug 2009, Robert Haas wrote:
On Wed, Aug 5, 2009 at 6:20 AM, Matthew Wakeling<matt...@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)
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
