Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 084D7633578 for ; Thu, 7 Jan 2010 12:34:15 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 27068-01 for ; Thu, 7 Jan 2010 16:34:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f204.google.com (mail-yw0-f204.google.com [209.85.211.204]) by mail.postgresql.org (Postfix) with ESMTP id 14D61633A6B for ; Thu, 7 Jan 2010 12:31:29 -0400 (AST) Received: by ywh42 with SMTP id 42so15927382ywh.28 for ; Thu, 07 Jan 2010 08:31:29 -0800 (PST) Received: by 10.101.132.10 with SMTP id j10mr2757058ann.84.1262881888845; Thu, 07 Jan 2010 08:31:28 -0800 (PST) Received: from ?192.168.0.80? (rrcs-64-183-7-130.west.biz.rr.com [64.183.7.130]) by mx.google.com with ESMTPS id 34sm8799237yxf.29.2010.01.07.08.31.26 (version=SSLv3 cipher=RC4-MD5); Thu, 07 Jan 2010 08:31:28 -0800 (PST) Message-ID: <4B460C5D.7080307@emolecules.com> Date: Thu, 07 Jan 2010 08:31:25 -0800 From: Craig James User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alvaro Herrera , Lefteris , Jochen Erwied , pgsql-performance@postgresql.org Subject: Re: Air-traffic benchmark References: <852badbc1001070438j36eb10d3qa22398ffcbef405f@mail.gmail.com> <4B45E36E.4040706@tweakers.net> <852badbc1001070547p48b47175vf87efc473e3bd41b@mail.gmail.com> <26014999.20100107150535@erwied.eu> <852badbc1001070610p698dc3cfr4628b1e7768990e6@mail.gmail.com> <20100107141423.GC4315@alvh.no-ip.org> In-Reply-To: <20100107141423.GC4315@alvh.no-ip.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=3.189 tagged_above=-10 required=5 tests=BAYES_50=0.001, FH_DATE_PAST_20XX=3.188 X-Spam-Level: *** X-Archive-Number: 201001/105 X-Sequence-Number: 36985 Alvaro Herrera wrote: > No amount of tinkering is going to change the fact that a seqscan is the > fastest way to execute these queries. Even if you got it to be all in > memory, it would still be much slower than the other systems which, I > gather, are using columnar storage and thus are perfectly suited to this > problem (unlike Postgres). The talk about "compression ratios" caught > me by surprise until I realized it was columnar stuff. There's no way > you can get such high ratios on a regular, row-oriented storage. One of the "good tricks" with Postgres is to convert a very wide table into a set of narrow tables, then use a view to create something that looks like the original table. It requires you to modify the write portions of your app, but the read portions can stay the same. A seq scan on one column will *much* faster when you rearrange your database this way since it's only scanning relevant data. You pay the price of an extra join on primary keys, though. If you have just a few columns in a very wide table that are seq-scanned a lot, you can pull out just those columns and leave the rest in the wide table. The same trick is also useful if you have one or a few columns that are updated frequently: pull them out, and use a view to recreate the original appearance. It saves a lot on garbage collection. Craig