From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Postgres Planner Bug |
Date: | 2002-10-01 04:40:35 |
Message-ID: | 18587.1033447235@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> The patch below 'fixes' this (and possibly breaks everything else). I
>> haven't tested it rigorously and it *just* special cases group by
>> clauses with functions in them.
Surely this cure is worse than the disease.
The general problem is that we don't attempt to match
arbitrary-expression GROUP BY clauses against arbitrary subexpressions
of sub-SELECTs. While that could certainly be done, I'm concerned about
the cycles that we'd expend trying to match everything against
everything else. This would be an exponential cost imposed on every
group-by-with-subselect query whether it needed the feature or not.
Given that GROUP BY is restricted to a simple column reference in both
SQL92 and SQL99, is it worth a large performance hit on unrelated
queries to support this feature? What other DBs support it?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alexey V. Borzov | 2002-10-01 05:00:29 | Re: [COMMITTERS] pgsql/contrib/rserv ApplySnapshot.in CleanLog. ... |
Previous Message | Gavin Sherry | 2002-10-01 04:34:03 | Re: Postgres Planner Bug |
From | Date | Subject | |
---|---|---|---|
Next Message | dima | 2002-10-01 07:52:51 | unsubscribe |
Previous Message | Gavin Sherry | 2002-10-01 04:34:03 | Re: Postgres Planner Bug |