Re: Improving scalability of Parallel Bitmap Heap/Index Scan

From: David Geier <geidav(dot)pg(at)gmail(dot)com>
To: John Naylor <johncnaylorls(at)gmail(dot)com>
Cc: shihao zhong <zhong950419(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Improving scalability of Parallel Bitmap Heap/Index Scan
Date: 2026-10-20 07:27:57
Message-ID: b61ae7f7-c249-4eca-9965-c529ea20d012@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> One thing I put under 0002 last time is really about 0001. With
>>> ST_COMPARE_RUNTIME_POINTER and a pointer element type, the typedef
>>> gives const Item ** but the sort passes Item **, so clang does not like it.
>>>
>>>
>>> Writing ST_ELEMENT_TYPE const * in the typedef fixes it.
>> I see. But seems like nothing in our code base triggers that. I leave it
>> to John to make the call if we want to fix that or leave as is for now.
>
> I'm not quite sure I follow -- v3 removed the typedef we were talking
> about earlier, and I understand Shihao to mean the warning was about
> v1. Is there another issue?
> One thing I put under 0002 last time is really about 0001

By that I understood that he accidentally put the following comment
under patch 0002 but it was meant for patch 0001:

> With ST_COMPARE_RUNTIME_POINTER the typedef
> uses const ST_ELEMENT_TYPE *, which for Item * becomes const Item **,
> so a comparator taking Item *const * warns. ST_ELEMENT_TYPE const *
> fixes it.

I thought this says that when ST_COMPARE_RUNTIME_POINTER is used, we can
further improve const-correctness. But patch 0002 doesn't use
ST_COMPARE_RUNTIME_POINTER, so this would be a separate improvement.

But maybe I got it wrong, Shihao?

--
David Geier

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Amit Kapila 2026-10-20 07:19:56 Re: [PG19] Promotion hangs behind a backend blocked on a stuck client