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
(index-cost + no-sorting) < (seqscan-cost + sort-cost)
assuming of course, that the costs turn out that way.
In response to
pgsql-performance by date
|Next:||From: Richard van den Berg||Date: 2004-01-09 14:12:42|
|Subject: Explain not accurate|
|Previous:||From: Dennis Björklund||Date: 2004-01-09 08:57:09|
|Subject: Re: Slow query problem|