From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | Dennis Björklund <db(at)zigo(dot)dhs(dot)org>, Bradley Tate <btate(at)objectmastery(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Slow query problem |
Date: | 2004-01-09 15:38:01 |
Message-ID: | 20040109073400.D69748@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 9 Jan 2004, Richard Huxton wrote:
> On Friday 09 January 2004 08:57, Dennis Bjrklund 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.
AFAICS, yes it does take that effect into account (as best
it can with the estimates).
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Creager | 2004-01-10 03:28:16 | Re: failures on machines using jfs |
Previous Message | Tom Lane | 2004-01-09 15:07:09 | Re: Slow query problem |