X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 581B9DA477; Thu, 6 Oct 2005 18:40:35 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 59436-08; Thu, 6 Oct 2005 21:40:27 +0000 (GMT) Received: from svana.org (svana.org [203.20.62.76]) by svr1.postgresql.org (Postfix) with ESMTP id 698E5DA47B; Thu, 6 Oct 2005 18:40:27 -0300 (ADT) Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) id 1ENdTN-0006y9-00; Fri, 07 Oct 2005 07:40:17 +1000 Date: Thu, 6 Oct 2005 23:40:17 +0200 From: Martijn van Oosterhout To: Tom Lane Cc: Ron Peacetree , "Jonah H. Harris" , pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org Subject: Re: [PERFORM] A Better External Sort? Message-ID: <20051006214017.GH10127@svana.org> Reply-To: Martijn van Oosterhout References: <138872.1128556455518.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> <20051006165725.GF10127@svana.org> <25130.1128628658@sss.pgh.pa.us> <20051006201447.GG10127@svana.org> <25400.1128630311@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ik0NlRzMGhMnxrMX" Content-Disposition: inline In-Reply-To: <25400.1128630311@sss.pgh.pa.us> User-Agent: Mutt/1.3.28i X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 X-PGP-Key-URL: X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.008 required=5 tests=[AWL=0.008] X-Spam-Level: X-Archive-Number: 200510/301 X-Sequence-Number: 74160 --ik0NlRzMGhMnxrMX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 06, 2005 at 04:25:11PM -0400, Tom Lane wrote: > Martijn van Oosterhout 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. >=20 > 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() =2E.. So didn't wonder if the straight sequential read was optimised. Still, I think pread() would be a worthwhile improvement, at least for Linux. --=20 Martijn van Oosterhout 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. --ik0NlRzMGhMnxrMX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFDRZnAIB7bNG8LQkwRAqq2AJ0QYtDrUJT31ViotfhMiVm0Spj1eACeJUGr ZxQKA/rJTo40yD2rpUd9CU0= =i1Ai -----END PGP SIGNATURE----- --ik0NlRzMGhMnxrMX--