From: | Vincenzo Romano <vincenzo(dot)romano(at)gmail(dot)com> |
---|---|
To: | "Dave Dutcher" <dave(at)tridecap(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Weird performance drop |
Date: | 2007-04-05 21:52:45 |
Message-ID: | 200704052352.45683.Vincenzo.Romano@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Friday 30 March 2007 16:34 Dave Dutcher wrote:
> > From: pgsql-performance-owner(at)postgresql(dot)org
> > [mailto:pgsql-performance-owner(at)postgresql(dot)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]
From | Date | Subject | |
---|---|---|---|
Next Message | Joseph S | 2007-04-06 00:25:11 | Re: ERROR: out of shared memory |
Previous Message | Erik Jones | 2007-04-05 21:39:12 | Re: a question about Direct I/O and double buffering |