From: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
---|---|
To: | John Hansen <john(at)geeknet(dot)com(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |
Date: | 2004-11-12 20:21:28 |
Message-ID: | 20041112202128.GB77327@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 11, 2004 at 08:00:01AM -0600, Bruno Wolff III wrote:
> On Thu, Nov 11, 2004 at 17:52:19 +1100,
> John Hansen <john(at)geeknet(dot)com(dot)au> wrote:
> > Why not just change the function all together to 'select $1 from $2
> > order by $1 desc limit 1;'
> >
> > Is there ANY situation where max(col) as it is, would be faster?
>
> Yes. A couple I can think of are:
> When count(col) is also being used.
Technically, wouldn't that depend on how many rows you were processing?
Certainly the time required for the CPU to compare the value of a field
in the current row to what it's got stored as the current maximum is
small compared to a disk read, but at some point it will be faster to
read an index.
> When a GROUP BY is being used and there isn't an index that can both be used
> to do the grouping and col order within each group.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2004-11-12 20:25:47 | Re: MAX/MIN optimization via rewrite (plus query |
Previous Message | schmidtm | 2004-11-12 19:57:55 | postgresql-8.0.0beta4 works/compiles fine under Mac OS X 10.3.6 |