| 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
| 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 |