From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, Andy Fan <zhihuifan1213(at)163(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Let plan_cache_mode to be a little less strict |
Date: | 2025-08-22 11:53:26 |
Message-ID: | 9549f477-92a3-4077-953b-1b42c770c218@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/8/2025 06:23, Michael Paquier wrote:
> On Fri, Aug 01, 2025 at 03:07:08PM +0200, Andrei Lepikhov wrote:
>> I considered the worker_spi.c module, which demonstrates various SPI usage
>> patterns. It might be more beneficial to use this instead of creating
>> another test module, isn't it?
>
> worker_spi is a playground for bgworker tests, so I'm not eager to
> make it more complex for the case of cached planned. SQL tests have
> more benefits here, IMO, and they should be more efficient and more
> predictible. worker_spi can only work with TAP.
I began to implement the idea, described above and got stuck on the
issue that we can't explain an SPI plan. It is possible to invent an
'auto_explain' approach (as a TAP test, of course), but it looks wrong.
As an alternative, it is feasible to add to the SPI interface an
SPI_explain_plan routine using the analogy of ExplainExecuteQuery. I
recall hearing some requests for this kind of feature before. Is this a
commitable way?
See the patch attached. Do I understand correctly the 'SPI wrapper'
approach?
--
regards, Andrei Lepikhov
Attachment | Content-Type | Size |
---|---|---|
v0-0001-Basic-routines-for-testing-saved-SPI-plans.patch | text/plain | 8.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2025-08-22 11:56:35 | Re: BackendKeyData is mandatory? |
Previous Message | Ashutosh Bapat | 2025-08-22 11:44:59 | Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring |