From: | Bob Jolliffe <bobjolliffe(at)gmail(dot)com> |
---|---|
To: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
Cc: | PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Query performance in 9.6.24 vs 14.10 |
Date: | 2024-01-29 18:21:05 |
Message-ID: | CACd=f9fLxuOgtfb0RRi08Qn5edPOFUBK_E5q-DyC4gBqU7KbMg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks for the update.
On Mon, Jan 29, 2024, 16:53 Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:
> According to my tests, sometimes JIT is a little faster, and sometimes
> it's a little slower. Mostly within the realm of statistical noise
> (especially with each query having a sample size of only 13, on a VM that
> lives on a probably-busy host).
>
> On Mon, Jan 29, 2024 at 9:18 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
> wrote:
>
>> Yes, jit=on.
>>
>> I'll test them with jit=off, to see the difference. (The application is
>> 3rd party, so will change it at the system level.)
>>
>> On Mon, Jan 29, 2024 at 7:09 AM Bob Jolliffe <bobjolliffe(at)gmail(dot)com>
>> wrote:
>>
>>> Out of curiosity, is the pg14 running with the default jit=on setting?
>>>
>>> This is obviously entirely due to the nature of the particular queries
>>> themselves, but we found that for our workloads that pg versions
>>> greater than 11 were exacting a huge cost due to the jit compiler. Once we
>>> explicitly turned jit=off we started to see improvements.
>>>
>>
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2024-01-29 18:27:02 | Re: Scriptable way to validate a pg_dump restore ? |
Previous Message | Shaheed Haque | 2024-01-29 18:12:17 | Re: Scriptable way to validate a pg_dump restore ? |