| From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
|---|---|
| To: | "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz> |
| Cc: | "Dave Cramer" <pg(at)fastcrypt(dot)com>, "Greg Stark" <gsstark(at)mit(dot)edu>, "Joshua Marsh" <icub3d(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Hardware/OS recommendations for large databases ( |
| Date: | 2005-11-19 16:15:29 |
| Message-ID: | BFA48FA1.14183%llonergan@greenplum.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Mark,
On 11/18/05 6:27 PM, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz> wrote:
> That too, meaning the business of 1 executor random reading a given
> relation file whilst another is sequentially scanning (some other) part
> of it....
I think it should actually improve things - each I/O will read 16MB into the
I/O cache, then the next scanner will seek for 10ms to get the next 16MB
into cache, etc. It should minimize the seek/data ratio nicely. As long as
the tables are contiguous it should rock and roll.
- Luke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig A. James | 2005-11-19 17:54:23 | Storage/Performance and splitting a table |
| Previous Message | Luke Lonergan | 2005-11-19 16:13:09 | Re: Hardware/OS recommendations for large databases ( |