From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Reinoud van Leeuwen <reinoud(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: optimizer question |
Date: | 2001-10-12 14:09:59 |
Message-ID: | 3BC6F9B7.15658A23@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> > >
> > > > "Reinoud van Leeuwen" <reinoud(at)xs4all(dot)nl> writes:
> > > > > I have a table that contains almost 8 milion rows. The primary key is a
> > > > > sequence, so the index should have a good distribution. Why does the
> > > > > optimizer refuse to use the index for getting the maximum value?
> > > >
> > > > The optimizer has no idea that max() has anything to do with indexes.
> > > > You could try something like
> > > >
> > > > select * from tab order by foo desc limit 1;
> > >
> > > Can we consider doing this optimization automatically?
> >
> > Only if we assume that people do not define their own max() that does
> > something
> > that can't be calculated using the above formula like calculating AVG().
>
> I hadn't thought of that one. I can't imagine a max() that doesn't
> match the ORDER BY collating.
But suppose you could have different indexes on the same column. For
example
for IP address you can theoretically define one index that indexes by
mask
length and other that indexes by numeric value of IP and yet another
that
indexes by some combination of both.
when doing an ORDER BY you can specify 'USING operator'
> Updated TODO item:
>
> * Use indexes for min() and max() or convert to SELECT col FROM tab
> ORDER BY col DESC LIMIT 1;
Maybe rather
* Use indexes for min() and max() or convert to "SELECT col FROM tab
ORDER BY col DESC USING max_index_op LIMIT 1" if there is an index
on tab that uses btree(col max_index_op)
it seems that in most other cases the rewrite would be either a
misoptimisation or plain wrong.
----------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Burton | 2001-10-12 14:28:43 | Re: Problem in pg_dump 7.1.2 dump order |
Previous Message | Thomas Lockhart | 2001-10-12 13:25:57 | [Fwd: Postgre SQL Developer - Chicago, IL] |