From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Steve Atkins <steve(at)blighty(dot)com>, pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Parallel sequential scans |
Date: | 2006-03-24 12:34:53 |
Message-ID: | 20060324123452.GZ90527@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Mar 24, 2006 at 01:44:19AM -0500, Tom Lane wrote:
> > Or I could fire off all the queries simultaneously and hope
> > they stay in close-enough lockstep through a single pass
> > through the table to be able to share most of the IO.
>
> I have not tried this sort of thing, but right offhand I like the second
> alternative. The "hope" is more well-founded than you seem to think:
> whichever process is currently ahead will be slowed by requesting I/O,
> while processes that are behind will find the pages they need already in
> shared buffers. You should definitely see just one read of each table
> page as the parallel scans advance, assuming you don't have an
> unreasonably small number of buffers.
>
> Another reason, if you have more than one CPU in your machine, is that
> multiple processes can make use of multiple CPUs, whereas the
> one-fancy-query approach doesn't parallelize (at least not without
> Bizgres or some such).
>
> And lastly, you can just try it without sweating hard to convert the
> queries ;-). So try it and let us know how it goes.
There was also a patch floating around that allowed seqscans to start in
the middle of a table if it was detected that a seqscan on that table
was already in progress. Not sure if that made it in, but it might be
relevant here.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-03-24 12:40:25 | Re: Practical limit on number of tables ina single database |
Previous Message | Jim C. Nasby | 2006-03-24 12:28:09 | Re: [GENERAL] COPY command documentation |