On Mon, 2023-11-20 at 15:52 -0500, Robert Haas wrote: > I agree. Not to burden you, but do you know what the overhead is now, > and do you have any plans to further reduce it? I don't believe > that's > the only thing we ought to be doing here, necessarily, but it is one > thing that we definitely should be doing and probably the least > controversial.
Running the simple test described here: https://www.postgresql.org/message-id/04c8592dbd694e4114a3ed87139a7a04e4363030.camel%40j-davis.com The baseline (no "SET search_path" clause on the function) is around 3800ms, and with the clause it shoots up to 8000ms. That's not good, but it is down from about 12000ms before. There are a few patches in the queue to bring it down further. Andres and I were discussing some GUC hashtable optimizations here: https://www.postgresql.org/message-id/27a7a289d5b8f42e1b1e79b1bcaeef3a40583bd2.ca...@j-davis.com which will (if committed) bring it down into the mid 7s. There are also a couple other patches I have here (and intend to commit soon): https://www.postgresql.org/message-id/e6fded24cb8a2c53d4ef069d9f69cc7baaafe9ef.camel%40j-davis.com and those I think will get it into the mid 6s. I think a bit lower combined with the GUC hash table optimizations above. So we are still looking at around 50% overhead for a simple function if all this stuff gets committed. Not great, but a lot better than before. Of course I welcome others to profile and see what they can do. There's a setjmp() call, and a couple allocations, and maybe some other stuff to look at. There are also higher-level ideas, like avoiding calling into guc.c in some cases, but that starts to get tricky as you pointed out: https://www.postgresql.org/message-id/CA%2BTgmoa8uKQgak5wH0%3D7sL-ukqbwnCPMXA2ZW7Ccdt7tdNGkzg%40mail.gmail.com It seems others are also interested in this problem, so I can put some more effort in after this round of patches goes in. I don't have a specific target other than "low enough overhead that we can reasonably recommend it as a best practice in multi-user environments". Regards, Jeff Davis
