From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Jean-Michel Pouré <jm(at)poure(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Feedback about Drupal SQL debugging |
Date: | 2009-08-22 01:55:07 |
Message-ID: | 25669.1250906107@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> The first step is probably to do the opposite of what we're talking
> about here: cases where people *have* added extra columns to the GROUP
> BY key so they can use those columns in their select list. We can
> remove those columns from the sort or hash comparison key if there's a
> column (or columns) which is a unique constraint key for the same
> source. Similarly we can remove columns from an ORDER BY if the order
> key has earlier columns which are already a unique key for the same
> source.
This is something we could only do at plan time --- if we do it at parse
time we risk making a robust query into one that will break when
somebody drops a constraint. So it's not really the inverse of the
other case.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gokulakannan Somasundaram | 2009-08-22 04:18:01 | Re: Lazy Snapshots |
Previous Message | Greg Stark | 2009-08-22 01:41:09 | Re: Feedback about Drupal SQL debugging |