Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id A62871336DB6 for ; Sat, 9 Oct 2010 23:10:46 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 75302-03 for ; Sun, 10 Oct 2010 02:10:41 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from joeconway.com (wsip-72-214-29-243.sd.sd.cox.net [72.214.29.243]) by mail.postgresql.org (Postfix) with ESMTP id E74CB1336473 for ; Sat, 9 Oct 2010 23:10:38 -0300 (ADT) Received: from [192.168.4.40] (account jconway HELO dev.joeconway.com) by joeconway.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 10185693; Sat, 09 Oct 2010 19:10:38 -0700 Message-ID: <4CB1209E.9000706@joeconway.com> Date: Sat, 09 Oct 2010 19:10:38 -0700 From: Joe Conway User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20071019 Fedora/1.5.0.12-3.fc6 pango-text Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: mladen.gogala@vmsinfo.com CC: Neil Whelchel , "pgsql-performance@postgresql.org" Subject: Re: Slow count(*) again... References: <201010091626.18636.neil.whelchel@gmail.com> <4CB11CC7.8070300@vmsinfo.com> In-Reply-To: <4CB11CC7.8070300@vmsinfo.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=B699434A Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC2028D29F7AEE8C01EAB6E81" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.918 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RDNS_DYNAMIC=0.982 X-Spam-Level: X-Archive-Number: 201010/80 X-Sequence-Number: 40499 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC2028D29F7AEE8C01EAB6E81 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/09/2010 06:54 PM, Mladen Gogala wrote: > In another database, whose name I will not mention, there is a paramete= r > db_file_multiblock_read_count which specifies how many blocks will be > read by a single read when doing a full table scan. PostgreSQL is in > dire need of something similar and it wouldn't even be that hard to > implement. You're correct in that it isn't particularly difficult to implement for sequential scans. But I have done some testing with aggressive read ahead, and although it is clearly a big win with a single client, the benefit was less clear as concurrency was increased. Joe --=20 Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support --------------enigC2028D29F7AEE8C01EAB6E81 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMsSCeAAoJEDfy90M199hlVk4QAI2pvomuDybexOMaHGJMPYdO 6/gm/7YCoVw5d9glgA8fQCZk991JZU1dHUa6tytNNaJQsY/JlEguAA9dVidI3Ypy 6KcKcAufUGmGunzDFmqM1aQKzUxNrIcqdzkKu6tDLOLxNzCLUWz7F64lMhMfy3xK /tFqETxgahDX8lqZiTPzB0yjqFA2QtaIsNMaVFHwJEOQpBIueDTr4OmC0uf1V9G0 62s9L0F6ML6jjXTcKkkxy+OnQn+YRhqq0Yb/zN5fcdOtmFoFyaj2h6vD8O3/9w3r Z9SXUPrXuuWRHRErPLWTrwlKtDzEign0BgpjFgvLwSyhimwUb9DU0k1WoOLIQtyq YUYiZbFGovXXFBdfGazsKHhQ85+H7dA/miUGOs5IQCsQSGkbOMH/jme8dfUCsDSv ppUwsWJb5IJ416X53TfTdJEulXIeb/C5CTTL3lpH4hzVdT+CFBSQ4Jg4SrF/1eRn /5JCMfX5cD+1Zd1bVuizrFS7ygP0n1RoEQMNbTkyBVhOAcD2pyMvQaPshj2tHDPr uYlqad8YHBi4oQiE1+WLvrCtE/55vFlfyODm4u7rHjg16u/KJhIRrCIYyy2X1K70 jH/wEbqHGN2PBmDRbeSSyxjXrWWI5wsqBKA2PeGsuY3+QrDI3V+apVGVSKYjPF04 cmO3WRLIdCfsRlmvM2lz =OEMl -----END PGP SIGNATURE----- --------------enigC2028D29F7AEE8C01EAB6E81--