Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: max() versus order/limit (WAS: High update
- From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
- To: Luke Lonergan <LLonergan(at)greenplum(dot)com>
- Cc: Adam Rich <adam(dot)r(at)sbcglobal(dot)net>, "Joshua D. Drake" <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Craig A. James" <cjames(at)modgraph-usa(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
- Subject: Re: max() versus order/limit (WAS: High update
- Date: Mon, 15 Jan 2007 07:38:09 -0300
Luke Lonergan wrote: > Adam, > > This optimization would require teaching the planner to use an index for > MAX/MIN when available. It seems like an OK thing to do to me. This optimization already exists, albeit for queries that use a single table. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
- References:
- Re: max() versus order/limit (WAS: High update
- From: Luke Lonergan
- Re: max() versus order/limit (WAS: High update
- Prev by Date: Re: max() versus order/limit (WAS: High update activity, PostgreSQL vs BigDBMS)
- Next by Date: Re: pg_trgm performance
- Previous by thread: Re: max() versus order/limit (WAS: High update
- Next by thread: Re: max() versus order/limit (WAS: High update
- Indexes: