Re: Restructuring plancache.c API

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Restructuring plancache.c API
Date: 2010-11-12 08:52:13
Message-ID: 4CDD003D.4090300@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2010-11-11 23:21, Tom Lane wrote:
> I've been thinking about supporting automatic replan of cached plans
> using specific parameter values, as has been discussed several times,
> at greatest length in this thread:
> http://archives.postgresql.org/pgsql-hackers/2010-02/msg00607.php
..
> I want to rearrange it so there's
> an explicit notion of three levels of cacheable object:
>
> 1. Raw parse tree + source string. These obviously never change.
In the context of cached plans and specific parameter values, a idea for
the future might be to also consider a cached plan for planning of
simple queries. A way to do this is by regarding all constants in a
simple query as parameters, and look for a cached plan for that
parameterized query. To lower the chance for choosing a bad plan for the
actual parameter values, a cached plan could also store the actual
parameter values used during planning. (where planning was done with
constants, not parameters, this would require back replacing the actual
values as constants in the parameterized query). Based on exact match on
the raw parse tree of the parameterized source tree and neighbourhood of
the actual parameter values of the cached and current query, a plan
could be chosen or not. If replanning was chosen, this new plan could
also be stored as new cached plan of the same query but with different
parameter values.

It would require one more level in the plan cache
1 raw parse tree of parameterized query
2 one or more "source string + actual parameter values" (these were the
replaced constants)
then for each entry in level 2 the remaining levels.

regards,
Yeb Havinga

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Wanner 2010-11-12 09:08:47 Re: multi-platform, multi-locale regression tests
Previous Message Yeb Havinga 2010-11-12 08:14:57 Re: wCTE behaviour