| 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: | Whole Thread | Raw Message | 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 |