Re: Common Table Expressions applied; some issues remain

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

In response to

Responses

Browse pgsql-hackers by date

  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