From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql - add special variable to reflect the last query status |
Date: | 2017-09-07 19:14:26 |
Message-ID: | CAFj8pRDKxFqGWjFr+UJjUsJ4R8kA2i8vB_TymxdPozB6tew+jg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
2017-09-06 11:14 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
>
> Here is a version 6.
>>
>
> Small v7 update, sorry for the noise.
>
> Add testing the initial state of all variables.
>
> Fix typos in a comment in tests.
>
> Fix the documentation wrt the current implementation behavior.
I rechecked last patch
There is not any issue with patching. All regress tests passed
I checked performance - the most fast queries are execution of simple
prepared statement
prepare x as select 1;
-- 1000000 x
execute x;
execute x;
execute x;
execute x;
## patched
[pavel(at)nemesis postgresql]$ time psql -At -1 postgres -f ~/xxx.sql >
/dev/null
real 0m44,887s
user 0m11,703s
sys 0m6,942s
This is probably the most worst case, what is possible and see some
slowdown - in this case there is about 10% slowdown -
but it is pretty untypical - the one query was less than 50 microsec. When
there will be any IO activity or network usage, than this patch doesn't
create any significant overhead.
I'll mark this patch as ready for commiter
Regards
Pavel
>
>
> --
> Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2017-09-07 19:30:22 | Re: PoC plpgsql - possibility to force custom or generic plan |
Previous Message | Robert Haas | 2017-09-07 19:04:14 | Re: Partition-wise join for join between (declaratively) partitioned tables |