Re: [9.0] On temporary tables

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: [9.0] On temporary tables
Date: 2010-09-30 14:13:45
Message-ID: AANLkTinALjoSQxLHwV3rNiUnrDZrLMEZ40ZXr2MZ+gwO@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello

2010/9/30 Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it>:
> 2010/9/30 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>> Hello
>>
>> 2010/9/30 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it> writes:
>>>> create or replace function session_init()
>>>> returns void
>>>> language plpgsql
>>>> as $body$
>>>> declare
>>>>   t text;
>>>> begin
>>>>   select valu into t from session where name='SESSION_ID';
>>>>   if not found then
>>>>     create temporary table session ( like public.session including all );
>>>>     insert into session values ( 'SESSION_ID',current_user );
>>>>   end if;
>>>> end;
>>>> $body$;
>>>
>>>> The idea is to create a temporary table to store session variables
>>>> only of there's no temporary table with that name.
>>>
>>> That isn't going to work tremendously well.  plpgsql will cache a plan
>>> for that SELECT on first use, and creation of the temp table is not an
>>> event that will cause replanning of a select that doesn't already use
>>> the temp table.
>>>
>>
>> I found a little bit faster solution a catching a exception.
>>
>> http://okbob.blogspot.com/2008/11/plpgsql-and-temp-tables.html
>
> Hmmm ... do you think the performance would be the same in v9?
>

yes I think

>> but if you need a session variables, then you can use a plperl
>>
>> http://www.postgresql.org/docs/9.0/static/plperl-global.html
>
> I will look into this. What I need is a set of variable for each connection.
>

understand - attention - session variables are nice but problematic
when you use some form of connection pooling

>> Regards
>>
>> Pavel Stehule
>
> Anyway, I'm quite puzzled by the fact that an EXCEPTION WHEN can be
> faster than an IF .. THEN .. ELSE
> with a rather simple test. Unless the pg_table_is_visible() is really bad.
>

can be - the reason is relative simple - exception is raised by
planner - so this doesn't do any real query - and lot of data for
planner are in cache.

Pavel

> Thanks a lot.
>
> --
> Vincenzo Romano at NotOrAnd Information Technologies
> Software Hardware Networking Training Support Security
> --
> NON QVIETIS MARIBVS NAVTA PERITVS
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vincenzo Romano 2010-09-30 14:25:48 Re: [9.0] On temporary tables
Previous Message Vincenzo Romano 2010-09-30 14:12:33 Re: [9.0] On temporary tables