| From: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Luke Lonergan" <LLonergan(at)greenplum(dot)com> |
| Cc: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Simon Riggs" <simon(at)enterprisedb(dot)com> |
| Subject: | Re: Seq scans roadmap |
| Date: | 2007-05-08 15:13:37 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA57901FD9726@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> >> What do you mean with using readahead inside the heapscan?
> >> Starting an async read request?
> >
> > Nope - just reading N buffers ahead for seqscans. Subsequent calls
> > use previously read pages. The objective is to issue
> contiguous reads
> > to the OS in sizes greater than the PG page size (which is much
> > smaller than what is needed for fast sequential I/O).
>
> Are you filling multiple buffers in the buffer cache with a
> single read-call?
yes, needs vector or ScatterGather IO.
> The OS should be doing readahead for us
> anyway, so I don't see how just issuing multiple ReadBuffers
> one after each other helps.
Last time I looked OS readahead was only comparable to 32k blocked
reads.
256k blocked reads still perform way better. Also when the OS is
confronted
with an IO storm the 256k reads perform way better than OS readahead.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ale Raza | 2007-05-08 15:41:16 | Patch: Allocation of "kind" codes for spatial type. |
| Previous Message | Zeugswetter Andreas ADI SD | 2007-05-08 15:09:04 | Re: Seq scans roadmap |