From: Craig James <craig_james@emolecules.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
To: Lefteris <lsidir@gmail.com>
To: Jochen Erwied <jochen@pgsql-performance.erwied.eu>
To: pgsql-performance@postgresql.org
Subject: Re: Air-traffic benchmark
Date: Thu, 07 Jan 2010 08:31:25 -0800
Message-ID: <4B460C5D.7080307@emolecules.com> (raw)
In-Reply-To: <20100107141423.GC4315@alvh.no-ip.org>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: craig_james@emolecules.com, alvherre@commandprompt.com, lsidir@gmail.com, jochen@pgsql-performance.erwied.eu
Subject: Re: Air-traffic benchmark
In-Reply-To: <4B460C5D.7080307@emolecules.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox