Re: SQL/JSON: JSON_TABLE - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: SQL/JSON: JSON_TABLE
Date
Msg-id 7d308e07-a633-2e78-77fb-bc26aaf8fb79@dunslane.net
Whole thread Raw
In response to Re: SQL/JSON: JSON_TABLE  (Stephen Frost <sfrost@snowman.net>)
Responses Re: SQL/JSON: JSON_TABLE  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On 4/6/22 11:11, Stephen Frost wrote:
> Greetings,
>
> * Andrew Dunstan (andrew@dunslane.net) wrote:
>> On 4/6/22 09:20, Andrew Dunstan wrote:
>>> On 4/5/22 22:21, Andres Freund wrote:
>>>> On 2022-03-27 16:53:57 -0400, Andrew Dunstan wrote:
>>>>> I'm therefore going to commit this series
>>>> The new jsonb_sqljson test is, on my machine, the slowest test in the main
>>>> regression tests:
>>>>
>>>> 4639 ms jsonb_sqljson
>>>> 2401 ms btree_index
>>>> 2166 ms stats_ext
>>>> 2027 ms alter_table
>>>> 1616 ms triggers
>>>> 1498 ms brin
>>>> 1489 ms join_hash
>>>> 1367 ms foreign_key
>>>> 1345 ms tuplesort
>>>> 1202 ms plpgsql
>>>>
>>>> Any chance the slowness isn't required slowness?
>>>
>>> I'll take a look.
>> I've committed a change that should reduce it substantially, but there
>> might be more work to do.
> All for improving the speed, but this broke the recovery tests (as
> noticed by the buildfarm).  Maybe we should add
> --no-unlogged-table-data to those pg_dumpall runs?



I think we should, but I think here the obvious solution is to drop the
table when we're done with it. I'll test that.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Practical Timing Side Channel Attacks on Memory Compression
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] pg_stat_toast