| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: GiST, caching, and consistency |
| Date: | 2009-08-05 14:11:54 |
| Message-ID: | 9731.1249481514@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Matthew Wakeling <matthew(at)flymine(dot)org> writes:
> 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?
Yeah, that's the syncscan logic biting you. You can turn it off if you
want.
> 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?
Yup, you're not scanning enough of the table to move the syncscan start
pointer.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2009-08-05 14:12:58 | Re: PostgreSQL 8.4 performance tuning questions |
| Previous Message | Matthew Wakeling | 2009-08-05 13:53:50 | Re: GiST, caching, and consistency |