Re: Slow query problem

From: Richard Huxton <dev(at)archonet(dot)com>
To: Dennis Björklund <db(at)zigo(dot)dhs(dot)org>
Cc: Bradley Tate <btate(at)objectmastery(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Slow query problem
Date: 2004-01-09 09:19:04
Message-ID: 200401090919.04718.dev@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Friday 09 January 2004 08:57, Dennis Björklund wrote:
> On Fri, 9 Jan 2004, Richard Huxton wrote:
> > > > select invheadref, invprodref, sum(units)
> > > > from invtran
> > > > group by invheadref, invprodref
> > >
> > > For the above query, shouldn't you have one index for both columns
> > > (invheadref, invprodref). Then it should not need to sort at all to do
> > > the grouping and it should all be fast.
> >
> > Not sure if that would make a difference here, since the whole table is
> > being read.
>
> The goal was to avoid the sorting which should not be needed with that
> index (I hope). So I still think that it would help in this case.

Sorry - not being clear. I can see how it _might_ help, but will the planner
take into account the fact that even though:
index-cost > seqscan-cost
that
(index-cost + no-sorting) < (seqscan-cost + sort-cost)
assuming of course, that the costs turn out that way.

--
Richard Huxton
Archonet Ltd

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Richard van den Berg 2004-01-09 14:12:42 Explain not accurate
Previous Message Dennis Björklund 2004-01-09 08:57:09 Re: Slow query problem