From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Query execution in Perl TAP tests needs work |
Date: | 2023-10-24 12:48:58 |
Message-ID: | 97d1d1b9-d147-f69d-1991-d8794efed41c@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2023-10-18 We 11:47, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Oct 18, 2023 at 10:28 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I did a bit of research on this on my favorite platforms, and did
>>> not like the results:
>> Hmm. That's unfortunate. Is perl -MCPAN -e 'install Platypus::FFI' a
>> viable alternative?
> Probably, see my followup.
>
>
Interesting. OK, here's an attempt to push the cart a bit further down
the road. The attached module wraps quite a lot of libpq, at least
enough for most of the cases we would be interested in, I think. It also
exports some constants such as connection status values, query status
values, transaction status values and type Oids. It also makes the
absence of FFI::Platypus not instantly fatal, but any attempt to use one
of the wrapped functions will die with a message about the module being
missing if it's not found.
I guess the next step would be for someone to locate some of the
hotspots in the TAP tests and try to convert them to using persistent
connections with this gadget or similar and see how much faster we can
make them.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
PqFFI.pm | application/x-perl | 12.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-10-24 12:58:04 | Re: Various bugs if segment containing redo pointer does not exist |
Previous Message | Julien Rouhaud | 2023-10-24 12:40:22 | Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements |