Re: Adding skip scan (including MDAM style range skip scan) to nbtree

From: Tomas Vondra <tomas(at)vondra(dot)me>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Adding skip scan (including MDAM style range skip scan) to nbtree
Date: 2025-05-09 22:54:10
Message-ID: 0fdeda96-9c8e-4bc1-bace-e78eaf9427f9@vondra.me
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/9/25 23:30, Matthias van de Meent wrote:
> ...
>> The difference shown by your flame graph is absolutely enormous --
>> that's *very* surprising to me. btbeginscan and btrescan go from being
>> microscopic to being very prominent. But skip scan simply didn't touch
>> either function, at all, directly or indirectly. And neither function
>> has really changed in any significant way in recent years. So right
>> now I'm completely stumped.
>
> I see some 60.5% of the samples under PostgresMain (35% overall) in
> the "bad" flamegraph have asm_exc_page_fault on the stack, indicating
> the backend(s) are hit with a torrent of continued page faults.
> Notably, this is not just in btree code: ExecInitIndexOnlyScan's
> components (ExecAssignExprContext,
> ExecConditionalAssignProjectionInfo, ExecIndexBuildScanKeys,
> ExecInitQual, etc.) are also very much affected, and none of those
> call into index code. Notably, this is before any btree code is
> executed in the query.
>
> In the "good" version, asm_exc_page_fault does not show up, at all;
> nor does sysmalloc.
>

Yes. Have you tried reproducing the issue? It'd be good if someone else
reproduced this independently, to confirm I'm not hallucinating.

> @Tomas
> Given the impact of MALLOC_TOP_PAD_, have you tested with other values
> of MALLOC_TOP_PAD_?
>

I tried, and it seems 4MB is sufficient for the overhead to disappear.
Perhaps some other mallopt parameters would help too, but my point was
merely to demonstrate this is malloc-related.

> Also, have you checked the memory usage of the benchmarked backends
> before and after 92fe23d93aa, e.g. by dumping
> pg_backend_memory_contexts after preparing and executing the sample
> query, or through pg_get_process_memory_contexts() from another
> backend?
>

I haven't noticed any elevated memory usage in top, but the queries are
very short, so I'm not sure how reliable that is. But if adding 4MB is
enough to make this go away, I doubt I'd notice a difference.

regards

--
Tomas Vondra

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-05-10 00:57:35 Re: Make COPY format extendable: Extract COPY TO format implementations
Previous Message John H 2025-05-09 22:45:13 Re: [PATCH] New predefined role pg_manage_extensions