| From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
|---|---|
| To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
| Cc: | mark(at)mark(dot)mielke(dot)cc, "Guy Thornley" <guy(at)esphion(dot)com>, "Markus Schaber" <schabi(at)logix-tt(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Large tables (was: RAID 0 not as fast as |
| Date: | 2006-09-25 14:23:58 |
| Message-ID: | C13D348E.283A%llonergan@greenplum.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Jim,
On 9/22/06 7:01 AM, "Jim C. Nasby" <jim(at)nasby(dot)net> wrote:
> There's been talk of adding code that would have a seqscan detect if
> another seqscan is happening on the table at the same time, and if it
> is, to start it's seqscan wherever the other seqscan is currently
> running. That would probably ensure that we weren't reading from the
> table in 2 different places, even if we weren't caching.
Right, aka "SyncScan"
The optimization you point out that we miss when bypassing cache is a pretty
unlikely event in real world apps, though it makes poorly designed
benchmarks go really fast. It's much more likely that the second seqscan
will start after the block cache is exhausted, which will cause actuator
thrashing (depending on the readahead that the OS uses). SyncScan fixes
that.
- Luke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | yoav x | 2006-09-25 14:58:17 | Re: PostgreSQL and sql-bench |
| Previous Message | Markus Schaber | 2006-09-25 08:47:40 | Re: Multi-processor question |