From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
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, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Subject: | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
Date: | 2025-05-09 13:33:11 |
Message-ID: | CAH2-Wz=SABjX0AEedf7Md2aXKi0KkVVdKSTDozrpsF3Z0WV2ZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 9, 2025 at 8:58 AM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
> My conclusion from this is that 92fe23d93aa ends up doing a lot of
> malloc calls, and this is what makes causes the regression. Otherwise
> setting the MALLOC_TOP_PAD_ would not help like this. But I haven't
> looked at the code, and I wouldn't have guessed the query to have
> anything to do with skip scan ...
While it's just about plausible that added nbtree preprocessing
allocation overhead could account for this, I don't think it's
actually possible here, since, as you said, this particular query
simply isn't eligible to use a skip scan. It's impossible for any
single column index to do so.
The best guess I have is that the skip scan commit inadvertently added
planner cycles, even though this query isn't eligible to use skip scan
-- I thought that I'd avoided that, but perhaps I overlooked some
subtlety.
Can you try it again, with prepared statements? Alternatively, you
could selectively revert the changes that commit 92fe23d93aa made to
utils/adt/selfuncs.c, and then retest.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2025-05-09 13:42:57 | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
Previous Message | Aleksander Alekseev | 2025-05-09 13:19:35 | Re: strange perf regression with data checksums |