| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Matt Clark" <matt(at)ymogen(dot)net> |
| Cc: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: slow plan for min/max |
| Date: | 2003-09-08 23:42:31 |
| Message-ID: | 9768.1063064551@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Matt Clark" <matt(at)ymogen(dot)net> writes:
> Actually, referring down to later parts of this thread, why can't this
> optimisation be performed internally for built-in types? I understand the
> issue with aggregates over user-defined types, but surely optimising max()
> for int4, text, etc is safe and easy?
I can't see that the datatype involved has anything to do with it.
None of the issues that come up in making the planner do this are
datatype-specific. You could possibly avoid adding some columns
to pg_aggregate if you instead hard-wired the equivalent knowledge
(for builtin types only) into some code somewhere, but a patch that
approached it that way would be rejected as unmaintainable.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Odiel León | 2003-09-09 00:38:23 | |
| Previous Message | Matt Clark | 2003-09-08 23:38:36 | Re: slow plan for min/max |