DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	b=QymQwm6TPBuwuLmGdtwn3ahmorAh3Bdj6TVxKGnanagkxkmvMWswOYOVzSX+7+SmVJ
	zsVFk9KwAVHUe44/9JhqPEbiQA+sAKDLrXKPB1rPmIqJkCJKCocvCObxtRiLLPj61ETG
	ZD2Hf/elirmb7yW9zWLL3GdevrsckQvUmBgWI=
MIME-Version: 1.0
In-Reply-To: <hi4sde$k7p$1@ger.gmane.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>
	<852badbc1001070623m5d901c42k50bb808409141ca4@mail.gmail.com>
	<hi4sde$k7p$1@ger.gmane.org>
Date: Thu, 7 Jan 2010 16:05:33 +0100
Message-ID: <852badbc1001070705w45ed93d6m385ea50da2221959@mail.gmail.com>
Subject: Re: Air-traffic benchmark
From: Lefteris <lsidir@gmail.com>
To: Ivan Voras <ivoras@freebsd.org>
Cc: pgsql-performance@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 7, 2010 at 3:51 PM, Ivan Voras <ivoras@freebsd.org> wrote:
> On 7.1.2010 15:23, Lefteris wrote:
>
>> I think what you all said was very helpful and clear! The only part
>> that I still disagree/don't understand is the shared_buffer option:))
>
> Did you ever try increasing shared_buffers to what was suggested (around
> 4 GB) and see what happens (I didn't see it in your posts)?

No I did not to that yet, mainly because I need the admin of the
machine to change the shmmax of the kernel and also because I have no
multiple queries running. Does Seq scan uses shared_buffers?

>
> Shared_buffers can be thought as the PostgreSQLs internal cache. If the
> pages being scanned for a particular query are in the cache, this will
> help performance very much on multiple exequtions of the same query.
> OTOH, since the file system's cache didn't help you significantly, there
> is low possibility shared_buffers will. It is still worth trying.
>
> From the description of the data ("...from years 1988 to 2009...") it
> looks like the query for "between 2000 and 2009" pulls out about half of
> the data. If an index could be used instead of seqscan, it could be
> perhaps only 50% faster, which is still not very comparable to others.
>
> The table is very wide, which is probably why the tested databases can
> deal with it faster than PG. You could try and narrow the table down
> (for instance: remove the Div* fields) to make the data more
> "relational-like". In real life, speedups in this circumstances would
> probably be gained by normalizing the data to make the basic table
> smaller and easier to use with indexing.
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>