Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group