On 09.12.2020 15:34, Pavel Stehule wrote:
Hi
st 9. 12. 2020 v 13:17 odesílatel Greg Nancarrow <gregn4...@gmail.com
<mailto:gregn4...@gmail.com>> napsal:
On Tue, Dec 8, 2020 at 3:26 PM Pavel Stehule
<pavel.steh...@gmail.com <mailto:pavel.steh...@gmail.com>> wrote:
>
>
> There are two maybe generic questions?
>
> 1. Maybe we can introduce more generic GUC for all event
triggers like disable_event_triggers? This GUC can be checked only
by the database owner or super user. It can be an alternative
ALTER TABLE DISABLE TRIGGER ALL. It can be protection against
necessity to restart to single mode to repair the event trigger. I
think so more generic solution is better than special
disable_client_connection_trigger GUC.
>
> 2. I have no objection against client_connection. It is probably
better for the mentioned purpose - possibility to block connection
to database. Can be interesting, and I am not sure how much work
it is to introduce the second event - session_start. This event
should be started after connecting - so the exception there
doesn't block connect, and should be started also after the new
statement "DISCARD SESSION", that will be started automatically
after DISCARD ALL. This feature should not be implemented in
first step, but it can be a plan for support pooled connections
>
I've created a separate patch to address question (1), rather than
include it in the main patch, which I've adjusted accordingly. I'll
leave question (2) until another time, as you suggest.
See the attached patches.
I see two possible questions?
1. when you introduce this event, then the new hook is useless ?
2. what is a performance impact for users that want not to use this
feature. What is a overhead of EventTriggerOnConnect and is possible
to skip this step if database has not any event trigger
As far as I understand this are questions to me rather than to Greg.
1. Do you mean client_connection_hook? It is used to implement this new
event type. It can be also used for other purposes.
2. Connection overhead is quite large. Supporting on connect hook
requires traversal of event trigger relation. But this overhead is
negligible comparing with overhead of establishing connection. In any
case I did the following test (with local connection):
pgbench -C -S -T 100 -P 1 -M prepared postgres
without this patch:
tps = 424.287889 (including connections establishing)
tps = 952.911068 (excluding connections establishing)
with this patch (but without any connection trigger defined):
tps = 434.642947 (including connections establishing)
tps = 995.525383 (excluding connections establishing)
As you can see - there is almost now different (patched version is even
faster, but it seems to be just "white noise".
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
