Re: *_collapse_limit, geqo_threshold

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "pgsql-hackers\(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: *_collapse_limit, geqo_threshold
Date: 2009-07-09 07:41:14
Message-ID: 874otmtiat.fsf@hi-media-techno.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Jul 8, 2009, at 8:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Now, your answer will probably be that we should provide some better
>> mechanism for re-using a previously identified plan structure. No
>> doubt that would be ideal, but the amount of effort required to get
>> there is nontrivial, and I'm not at all convinced it would be repaid
>> in usefulness. Whereas what I describe above is something that costs
>> us nearly nothing to provide. The usefulness might be marginal too,
>> but on the basis of cost/benefit ratio it's a clear win.
>
> I don't think that would be my answer because plan caching sounds hard. It
> would be nice to have, though. :-)

In fact I think marshalling plans (and unmarshalling them) would rather
be the easy part of it, what looks very hard is the problem already
mentioned here in another context (gathering statistics on views):
http://archives.postgresql.org/pgsql-performance/2009-06/msg00118.php

How to match a random user query with the stored plans with as little
analyze as possible?

> But it's clearly a planner hint, however you slice it.

Agreed.

Regards,
--
dim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2009-07-09 07:58:14 Re: modules missing from Application Stack Wizard?
Previous Message Fujii Masao 2009-07-09 07:16:25 Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby