DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:from;
	b=kbJ16fNHr/603VtOs4fOjIyeprVBpGFJhFMxKKTRAOaNABNsS2xGR1mzcI572BeksnmnidFB8ItmhkXqXMoztsFy/IExUXDVExJ6CBdo0o1YedXaXjQ8HA2zjQPNALIfDYBoEO7yaqOomCX7cAWnrdqEgzgtCs69+zamUipBcCs=
To: "Dave Dutcher" <dave@tridecap.com>
Subject: Re: Weird performance drop
Date: Thu, 5 Apr 2007 23:52:45 +0200
User-Agent: KMail/1.9.5
Cc: pgsql-performance@postgresql.org
References: <01ea01c772d8$7b87aca0$2e00a8c0@tridecap.com>
In-Reply-To: <01ea01c772d8$7b87aca0$2e00a8c0@tridecap.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200704052352.45683.Vincenzo.Romano@gmail.com>
From: Vincenzo Romano <vincenzo.romano@gmail.com>

On Friday 30 March 2007 16:34 Dave Dutcher wrote:
> > From: pgsql-performance-owner@postgresql.org
> > [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of
> > Vincenzo Romano
> >
> > Is there any "workaround"?
> >
> > In my opinion the later the query planner decisions are taken the more
> > effective they can be.
> > It could be an option for the function (body) to delay any
> > query planner
> > decision.
>
> I think a possible workaround is to use a plpgsql function and the execute
> statement. The docs will have more info.
>
> Dave

Aye sir. It works.

There's not much details into the documentation but the real point is
that the execute command of the PLPg/SQL actually says the DB to delay
the query planning process as late as possible,

I have also managed to build search functions at runtime using the execute
command with a dynamically built text variable.
Complex, error prone but really fast.

-- 
Vincenzo Romano
----
Maybe Computers will never become as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1987]