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
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 |