Re: Plan invalidation vs. unnamed prepared statements

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>, <pgsql-jdbc(at)postgreSQL(dot)org>
Subject: Re: Plan invalidation vs. unnamed prepared statements
Date: 2007-03-06 18:04:16
Message-ID: 87fy8i9rkv.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc


"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> B. Don't store the unnamed statement in the plan cache. To make sure
> it's not used anymore when the plan might be stale, forcibly discard
> the unnamed statement after execution. This would get rid of a lot
> of overhead but would mean a significant change in the protocol-level
> behavior. It's hard to guess how many clients might be broken by it
> --- conceivably not any, but that seems too optimistic :-(

Can we forcibly discard it if *any* messages are received that might
invalidate a plan? So basically it would work fine unless anyone in the system
does any DDL at all? I guess that has the downside of introducing random
unpredictable failures.

Or stash the query string and replan it (possibly in the query cache this
time) if someone executes it a second time?

Can't say I like either of those options much, just trying to brainstorm.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2007-03-06 18:09:42 Re: Bug: Buffer cache is not scan resistant
Previous Message Tom Lane 2007-03-06 18:02:49 Re: PostgreSQL - 'SKYLINE OF' clause added!

Browse pgsql-jdbc by date

  From Date Subject
Next Message Tom Lane 2007-03-06 18:14:42 Re: Plan invalidation vs. unnamed prepared statements
Previous Message Tom Lane 2007-03-06 17:22:57 Plan invalidation vs. unnamed prepared statements