From: | Decibel! <decibel(at)decibel(dot)org> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Yoshiyuki Asaba <y-asaba(at)sraoss(dot)co(dot)jp>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Common Table Expressions applied; some issues remain |
Date: | 2008-10-06 15:36:32 |
Message-ID: | 814D6CF7-5AD9-4B43-90F4-C8775B4B2DD7@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Oct 5, 2008, at 1:11 AM, Peter Eisentraut wrote:
> I don't think we should overload syntax choices with optimization
> hints. We don't really know why or how people will be using this
> syntax, and labeling it from the start as "will have unusual
> performance behavior" isn't a good sell.
>
> As a precedent, consider the JOIN syntax, which is obviously
> redundant and in its first implementation contained an implicit
> optimization hint with regard to join order that later had to be
> done away with because it confused users (I think). The CTE case
> is quite similar, and maybe the GUC answer of old could apply here
> as well. But I think by default we should abide by SQL's
> declarative approach of "Tell me what you want and I'll execute it
> any way I like."
Agreed. It's already horrible that we suggest people use OFFSET 0,
only because we don't want to define formal optimizer hints (and
that's *exactly* what OFFSET 0 is).
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
From | Date | Subject | |
---|---|---|---|
Next Message | Decibel! | 2008-10-06 15:44:36 | Re: FSM rewrite committed, loose ends |
Previous Message | Decibel! | 2008-10-06 15:29:37 | Re: Add default_val to pg_settings |