Re: Query execution in Perl TAP tests needs work

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

In response to

Browse pgsql-hackers by date

  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