The MAJOR benefit of Microsoft's approach is that it works on existing
application,
Yes, that is a nice benefit !
Is there a way to turn it on/off ? Or is it smart enough to only cache
plans for cases where it is relevant ?
For instance, I absolutely want some queries to be planne
Tom Lane wrote:
PFC <[EMAIL PROTECTED]> writes:
Do the parse tree store fully qualified "schema.table" or
"schema.function" ?
They store OIDs.
So, what happens if we reference a temporary table or something else
that requires resolution
down a search path?
I believe Microsoft a
PFC <[EMAIL PROTECTED]> writes:
> Do the parse tree store fully qualified "schema.table" or
> "schema.function" ?
They store OIDs.
> I mean, if table T is mentioned in a parse tree which is stored, and
> the
> table is later dropped and recreated... or a column dropped... what
* Server restart and assorted like failover (you need to redo a
global prepare).
Hmm? He's proposing storing the info in a system catalog. That hardly
seems "volatile"; it'll certainly survive a server restart.
Yes, it's in a system catalog.
I agree with the point that th
Joris Dobbelsteen <[EMAIL PROTECTED]> writes:
> The MAJOR benefit of Microsoft's approach is that it works on existing
> application, and, most importantly makes NO assumptions on the
> "volatile" server state. A few cases where the Microsoft solution works,
> while yours will fail is:
> *
PFC wrote:
PFC wrote:
Hello,
So, I embarked (yesterday) on a weekend project to add a new
feature to Postgres...
I use PHP with persistent connections and always have been
bothered that those very small AJAX queries (usually simple selects
returning 1 row) take more CPU in postgre
PFC wrote:
Hello,
So, I embarked (yesterday) on a weekend project to add a new
feature to Postgres...
I use PHP with persistent connections and always have been bothered
that those very small AJAX queries (usually simple selects returning 1
row) take more CPU in postgres to pa
PFC wrote:
Hello,
So, I embarked (yesterday) on a weekend project to add a new
feature to Postgres...
I use PHP with persistent connections and always have been
bothered that those very small AJAX queries (usually simple selects
returning 1 row) take more CPU in postgres to parse &
Hello,
So, I embarked (yesterday) on a weekend project to add a new feature to
Postgres...
I use PHP with persistent connections and always have been bothered that
those very small AJAX queries (usually simple selects returning 1 row)
take more CPU in postgres to parse & plan than
