From: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: One-Shot Plans |
Date: | 2011-06-21 06:51:11 |
Message-ID: | BANLkTi==9E3cPeBXAXTd-fUOxSzQKPyqGg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 14, 2011 at 1:25 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> We can work out the various paths through the traffic cop to see when
> a plan will be a "one-shot" - planned and then executed immediately,
> then discarded.
>
> In those cases we can take advantage of better optimisations. Most
> interestingly, we can evaluate stable functions at plan time, to allow
> us to handle partitioning and partial indexes better.
>
> Patch attached. Works...
>
this breaks test guc.c for me... specifically the test at
src/test/regress/sql/guc.sql circa line 226:
"""
set work_mem = '3MB';
-- but SET isn't
create or replace function myfunc(int) returns text as $$
begin
set work_mem = '2MB';
return current_setting('work_mem');
end $$
language plpgsql
set work_mem = '1MB';
select myfunc(0), current_setting('work_mem');
"""
regressions.diff
"""
*** 656,662 ****
select myfunc(0), current_setting('work_mem');
myfunc | current_setting
--------+-----------------
! 2MB | 2MB
(1 row)
set work_mem = '3MB';
--- 656,662 ----
select myfunc(0), current_setting('work_mem');
myfunc | current_setting
--------+-----------------
! 2MB | 3MB
(1 row)
set work_mem = '3MB';
"""
it seems that the effect of SET is being discarded
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Keller | 2011-06-21 08:04:12 | hstore - Implementation and performance issues around its operators |
Previous Message | Pavel Stehule | 2011-06-21 04:59:44 | Re: Fwd: Keywords in pg_hba.conf should be field-specific |