| From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Ron Peacetree <rjpeace(at)earthlink(dot)net>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: [PERFORM] A Better External Sort? |
| Date: | 2005-10-06 21:40:17 |
| Message-ID: | 20051006214017.GH10127@svana.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On Thu, Oct 06, 2005 at 04:25:11PM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > Are we awfully worried about people still using 2.0 kernels? And it
> > would replace two calls with three in the worst case, we currently
> > lseek before every read.
>
> That's utterly false.
Oops, you're right. I usually strace during a vacuum or a large query
and my screen fills up with:
lseek()
read()
lseek()
read()
...
So didn't wonder if the straight sequential read was optimised. Still,
I think pread() would be a worthwhile improvement, at least for Linux.
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2005-10-07 00:02:41 | slower merge join on sorted data chosen over nested loop |
| Previous Message | Jim C. Nasby | 2005-10-06 21:31:27 | Re: prefix btree implementation |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Frost | 2005-10-06 23:55:27 | Status of Opteron vs Xeon |
| Previous Message | Lane Van Ingen | 2005-10-06 21:29:42 | Need Some Suggestions |