Skip site navigation (1) Skip section navigation (2)

Re: Strange workaround for slow query

From: Sander Verhagen <sverhagen(at)wps-nl(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-performance(at)postgresql(dot)org,Robert Haas <robertmhaas(at)gmail(dot)com>,Yeb Havinga <yebhavinga(at)gmail(dot)com>
Subject: Re: Strange workaround for slow query
Date: 2010-05-29 21:13:40
Message-ID: OF645E063A.0499CDD2-ONC1257732.00744183-C1257732.00749BDE@imtechrelay.nl (view raw or flat)
Thread:
Lists: pgsql-performance
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote on 10-03-2010 23:37:20:

> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> 10-03-2010 23:37
>
> Right now, nodeNestloop is not really aware of whether the inner scan
> depends on any parameters from the outer scan, so it's a bit hard to
> determine whether the join can be abandoned.  However, I have 9.1
> plans to change that --- I'd like to get rid of the current
> pass-the-outer-tuple-to-ReScan hack entirely, in favor of having
> nodeNestloop explicitly set PARAM_EXEC parameters for the inner scan.
> Once that's in, it would be pretty easy to apply this optimization.

I've made it my personal standard to sit mailing list discussions out to
the end, report back on results, etc. This one has been sitting in my Inbox
for a couple of months now, waiting for me to respond. But the truth is:
you're going way over my head. And that is fine, you seem to know of the
inner workings of PostgreSQL, and I'll be waiting for future versions that
may well solve my problem -- or not, it being a great product either way.
Keep up the good work, Sander.

In response to

pgsql-performance by date

Next:From: Jesper KroghDate: 2010-05-30 17:41:22
Subject: planner costs in "warm cache" tests
Previous:From: Kevin GrittnerDate: 2010-05-29 17:01:21
Subject: Re: Wildly inaccurate query plan

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group