> On 2 Oct 2023, at 20:10, Robert Haas <robertmhaas@gmail.com> wrote:
>
> Sorry to have gone dark on this for a long time after having been
> asked for my input back in March. I'm not having a great time trying
> to keep up with email, and the threads getting split up makes it a lot
> worse for me.
Not a problem, thanks for chiming in.
> On Fri, Sep 29, 2023 at 6:15 AM Daniel Gustafsson <daniel@yesql.se> wrote:
>> Running the same pgbench command on my laptop looking at the average connection
>> times, and the averaging that over five runs (low/avg/high) I see ~5% increase
>> over master with the patched version (compiled without assertions and debug):
>>
>> Patched event_triggers on: 6.858 ms/7.038 ms/7.434 ms
>> Patched event_triggers off: 6.601 ms/6.958 ms/7.539 ms
>> Master: 6.676 ms/6.697 ms/6.760 ms
>
> This seems kind of crazy to me. Why does it happen? It sounds to me
> like we must be doing a lot of extra catalog access to find out
> whether there are any on-login event triggers. Like maybe a sequential
> scan of pg_event_trigger.
That's exactly what happens, the patch is using BuildEventTriggerCache() to
build the hash for EVT which is then checked for login triggers. This is
clearly the bottleneck and there needs to be a fast-path. There used to be a
cache flag in an earlier version of the patch but it was a but klugy, a version
of that needs to be reimplemented for this patch to fly.
> I think a lot of users would say that logins on PostgreSQL are too slow already.
Agreed.
--
Daniel Gustafsson