Date: Tue, 8 Nov 2005 12:48:45 -0800 (PST)
From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Luke Lonergan <llonergan@greenplum.com>
Cc: Simon Riggs <simon@2ndquadrant.com>,
	Kurt Harriman <kharriman@greenplum.com>, pgsql-performance@postgresql.org
Subject: Re: Sort performance on large tables
In-Reply-To: <BF9637D3.1338F%llonergan@greenplum.com>
Message-ID: <20051108124255.Y43056@megazone.bigpanda.com>
References: <BF9637D3.1338F%llonergan@greenplum.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE


On Tue, 8 Nov 2005, Luke Lonergan wrote:

> Stephan,
>
> On 11/8/05 9:38 AM, "Stephan Szabo" <sszabo@megazone.bigpanda.com> wrote:
>
> >> >
> >> > Just as we find with a similar comparison (with a "popular commercia=
l,
> >> > proprietary database" :-) Though some might suggest you increase
> >> > work_mem or other tuning suggestions to speed sorting, none work.  I=
n
> >> > fact, we find that increasing work_mem actually slows sorting slight=
ly.
> >
> > I wish you'd qualify your statements, because I can demonstrably show t=
hat
> > I can make sorts go faster on my machine at least by increasing work_me=
m
> > under some conditions.
> >
> Cool =AD can you provide your test case please?

I probably should have added the wink smiley to make it obvious I was
talking about the simplest case, things that don't fit in work_mem at the
current level but for which it's easy to raise work_mem to cover. It's not
a big a gain as one might hope, but it does certainly drop again.

> Recognize also that we=B9re looking for a factor of 10 or more improvemen=
t
> here =AD this is not a small increase that=B9s needed.

I agree that we definately need help on that regard.  I do see the effect
where raising work_mem lowers the performance up until that point.  I just
think that it requires more care in the discussion than disregarding the
suggestions entirely especially since people are going to see this in the
archives.