Re: optimizer question

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

In response to

Responses

Browse pgsql-hackers by date

  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]