| From: | Gary Chambers <gwchamb(at)gmail(dot)com> |
|---|---|
| To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
| Cc: | Thomas Kellerer <spam_eater(at)gmx(dot)net>, pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: 8.4.1 distinct query WITHOUT order by |
| Date: | 2009-12-22 03:45:27 |
| Message-ID: | 302670f20912211945n1b6684e9xb304d4508766f117@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
> Yeah, if you're code base is that fragile, bandaging it up by jumping
> through hoops in pgsql is just putting off the inevitable when it (the
> code base) has to get recompiled someday anyway.
I appreciate (and agree with) the concern about the fragility of the
codebase. The maintainer knows that anything except adding ORDER BY
is a kludge.
Now, the aforementioned notwithstanding...
Aside from disabling enable_hashagg (which, according to the
documentation, is performance-expensive), what other options do I
have?
What are the ramifications of renaming the table (containing 8000
rows) and creating a view of the same name?
Assuming it's possible, would the efficiency of a rule to rewrite the
query be an acceptable alternative?
Thanks in advance for any insight and suggestions!
-- Gary Chambers
/* Nothing fancy and nothing Microsoft! */
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2009-12-22 05:18:11 | Re: 8.4.1 distinct query WITHOUT order by |
| Previous Message | Scott Marlowe | 2009-12-21 22:53:04 | Re: 8.4.1 distinct query WITHOUT order by |