Date: Thu, 7 Jan 2010 11:14:23 -0300
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Lefteris <lsidir@gmail.com>
Cc: Jochen Erwied <jochen@pgsql-performance.erwied.eu>,
	pgsql-performance@postgresql.org
Subject: Re: Air-traffic benchmark
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <852badbc1001070610p698dc3cfr4628b1e7768990e6@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

Lefteris escribió:
> Yes, I am reading the plan wrong! I thought that each row from the
> plan reported the total time for the operation but it actually reports
> the starting and ending point.
> 
> So we all agree that the problem is on the scans:)
> 
> So the next question is why changing shared memory buffers will fix
> that? i only have one session with one connection, do I have like many
> reader workers or something?

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.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support