> In my tests I build from source from both the 17 stable and head branch
> and use the same build options.
>
OK, I built 17 from REL_17_STABLE, and got the same behavior as the
Homebrew PG17:
* First run: 135 ms
* Subsequent runs: 169 ms, 181 ms, 187 ms, 177 ms, 170 ms
For comparison, with PG18
> I'm now thinking maybe the compilation options for PG 17.5 have been
> different. I'm using the default version that comes with Homebrew, but for
> PG 18, I compiled it myself. Here are the results for `select version();`
> on both:
>
> PostgreSQL 17.5 (Homebrew) on aarch64-apple-darwin24.4.0,
>
Thanks, very interesting insights!
Can you try the same test ( with --no-data-checksums) on you mac
> and see if that makes a difference?
>
I disabled checksums on PG18, and retried the tests, with and without
modifying random_page_cost, and for TEMP tables only.
When random_page_cost is the def
On Sat, May 17, 2025 at 2:00 PM Sadeq Dousti wrote:
>>
>> thanks. I don't see regression for a normal table, at least for this test.
>
>
> No, there isn't. I just added them as per your request ;)
>
>
>> In terms of your original test, I tried it out on my Ubuntu machine
>>
>> and with your test a
On Sat, May 17, 2025 at 12:38 PM Sadeq Dousti wrote:
> So, one mystery solved (no planner regression), still three questions:
> * Somewhat slower execution in PG18
I cannot recreate the problem.
The fastest plan for this query is a parallel sequential scan -- the
t_i_j_k_idx index is useless. T
>
> thanks. I don't see regression for a normal table, at least for this test.
>
No, there isn't. I just added them as per your request ;)
In terms of your original test, I tried it out on my Ubuntu machine
and with your test as-is, I see 2.8 seconds on 17.5 and 3.3 seconds
on HEAD if the plan
>> I'll be curious about tests with a normal table as well with a
>> sufficiently large shared_buffers.
> Here are results for a normal table with default shared_buffers (128 MB) and
> large shared_buffers (4GB):
thanks. I don't see regression for a normal table, at least for this test.
In term
>
> Yes, this is intentional as of 95dbd827f2edc
>
Thanks!
> >> > * Changing the table from TEMP to UNLOGGED makes both versions use
> >> > "Parallel Seq Scan", with PG18 being ~25% faster. (190ms vs. 150ms).
>
> I'll be curious about tests with a normal table as well with a
> sufficiently large
On Sat, May 17, 2025 at 9:38 AM Sadeq Dousti wrote:
> So, one mystery solved (no planner regression), still three questions:
> * Somewhat slower execution in PG18
> * Planner differences in TEMP vs. UNLOGGED
> * Actual rows with decimal (1.00) vs. integer (1)
>
Regarding the last one, I believe
>> > * Also, I noticed "explain analyze" reports actual rows as a decimal
>> > number (1.00) as opposed to an integer (1); not sure if that's intentional.
Yes, this is intentional as of 95dbd827f2edc
>> > * Changing the table from TEMP to UNLOGGED makes both versions use
>> > "Parallel Seq Scan",
Hi,
You're right, with settings, it revealed that PG17 had random_page_cost=1.1
configured.
Adding that to PG18 sets the plan to index only; however, PG18 is still
somewhat (~15%) slower:
PG17.5 =
QUERY PLAN
Dear all,
I was testing PG18 beta 1 new features (noticeably, AIO and index skip
scan), and I came up with this example:
===
drop table if exists t;
create TEMP table t(i,j,k)
as select n,n,n
from generate_series(1,10_000_000) as n;
analyze t;
create index on t(i,j,k);
explain (analyz
12 matches
Mail list logo
