On Tue, Nov 20, 2012 at 02:24:01PM -0600, Merlin Moncure wrote:
> On Tue, Nov 20, 2012 at 1:53 PM, Jon Nelson wrote:
> > As can be seen by the current conversation, not everyone is convinced
> that CTEs ought to be an explicit optimization barrier
>
> On Tue, Nov 20, 2012 at 1:26 PM, Claudio Frei
I'd also add ANALYZED/NOT ANALYZED. This should force it behave like
'create table, analyze, select' with statistics used in second query plan.
P.S. defaults can be configurable.
20 лист. 2012 02:22, "Gavin Flower" напис.
> On 15/11/12 15:03, Peter Geoghegan wrote:
>
>> On 15 November 2012 01:46
On 11/21/2012 03:53 AM, Jon Nelson wrote:
> My perspective on this is that CTEs *should* be just like creating a
> temporary table and then joining to it, but without the
> materialization costs. In that respect, they seem like they should be
> like nifty VIEWs. If I wanted the behavior of material
Jon Nelson writes:
> ... Perhaps even including a
> small blurb about what an optimization barrier even means (my
> understanding is that it merely forces materialization of that part of
> the query).
FWIW, it has nothing to do with materialization; it means that we don't
push conditions down int
On Tue, Nov 20, 2012 at 5:24 PM, Merlin Moncure wrote:
> On Tue, Nov 20, 2012 at 1:53 PM, Jon Nelson wrote:
>> As can be seen by the current conversation, not everyone is convinced
> that CTEs ought to be an explicit optimization barrier
>
> On Tue, Nov 20, 2012 at 1:26 PM, Claudio Freire
> wro
On Tue, Nov 20, 2012 at 1:53 PM, Jon Nelson wrote:
> As can be seen by the current conversation, not everyone is convinced
that CTEs ought to be an explicit optimization barrier
On Tue, Nov 20, 2012 at 1:26 PM, Claudio Freire wrote:
> It *could* just be a lack of imagination on my part. But if i
My perspective on this is that CTEs *should* be just like creating a
temporary table and then joining to it, but without the
materialization costs. In that respect, they seem like they should be
like nifty VIEWs. If I wanted the behavior of materialization and then
join, I'd do that explicitly with
On Tue, Nov 20, 2012 at 4:22 PM, Merlin Moncure wrote:
> On Wed, Nov 14, 2012 at 8:03 PM, Peter Geoghegan
> wrote:
>> On 15 November 2012 01:46, Andrew Dunstan wrote:
>>> It cuts both ways. I have used CTEs a LOT precisely because this behaviour
>>> lets me get better plans. Without that I'll b
On Wed, Nov 14, 2012 at 8:03 PM, Peter Geoghegan wrote:
> On 15 November 2012 01:46, Andrew Dunstan wrote:
>> It cuts both ways. I have used CTEs a LOT precisely because this behaviour
>> lets me get better plans. Without that I'll be back to using the "offset 0"
>> hack.
>
> Is the "OFFSET 0" ha
On 15/11/12 15:03, Peter Geoghegan wrote:
On 15 November 2012 01:46, Andrew Dunstan wrote:
It cuts both ways. I have used CTEs a LOT precisely because this behaviour
lets me get better plans. Without that I'll be back to using the "offset 0"
hack.
Is the "OFFSET 0" hack really so bad? We've be
On 15 November 2012 01:46, Andrew Dunstan wrote:
> It cuts both ways. I have used CTEs a LOT precisely because this behaviour
> lets me get better plans. Without that I'll be back to using the "offset 0"
> hack.
Is the "OFFSET 0" hack really so bad? We've been telling people to do
that for years,
On 11/14/2012 08:17 PM, Craig Ringer wrote:
On 11/15/2012 12:29 AM, Tom Lane wrote:
David Greco writes:
Thanks, that did the trick. Though I'm still not clear as to why.
PG treats WITH as an optimization fence --- the WITH query will be
executed pretty much as-is. It may be that Oracle flat
Craig Ringer writes:
> I was looking through the latest spec drafts I have access to and
> couldn't find any reference to Pg's optimisation-fence-for-CTEs
> behaviour being required by the standard, though I've repeatedly seen it
> said that there is such a requirement.
I don't believe it's requi
On 11/15/2012 12:29 AM, Tom Lane wrote:
> David Greco writes:
>> Thanks, that did the trick. Though I'm still not clear as to why.
> PG treats WITH as an optimization fence --- the WITH query will be
> executed pretty much as-is. It may be that Oracle flattens the query
> somehow; though if you'
David Greco writes:
> Thanks, that did the trick. Though I'm still not clear as to why.
PG treats WITH as an optimization fence --- the WITH query will be
executed pretty much as-is. It may be that Oracle flattens the query
somehow; though if you're using black-box functions in both cases,
it's
15 matches
Mail list logo
