From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, David Geier <geidav(dot)pg(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE |
Date: | 2024-03-14 20:59:50 |
Message-ID: | f4b80948-4f81-4db8-b7a7-662d3b58da4e@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14/03/2024 22:00, Melanie Plageman wrote:
> On Thu, Mar 14, 2024 at 05:30:30PM +0200, Heikki Linnakangas wrote:
>> typedef struct SharedBitmapHeapInstrumentation
>> {
>> int num_workers;
>> BitmapHeapScanInstrumentation sinstrument[FLEXIBLE_ARRAY_MEMBER];
>> } SharedBitmapHeapInstrumentation;
>>
>> typedef struct BitmapHeapScanState
>> {
>> ScanState ss; /* its first field is NodeTag */
>> ...
>> SharedBitmapHeapInstrumentation sinstrument;
>> } BitmapHeapScanState;
>>
>> that compiles, at least with my compiler, but I find it weird to have a
>> variable-length inner struct embedded in an outer struct like that.
>
> In the attached patch, BitmapHeapScanState->sinstrument is a pointer,
> though. Or are you proposing the above as an alternative that you
> decided not to go with?
Right, the above is what I contemplated at first but decided it was a
bad idea.
--
Heikki Linnakangas
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-03-14 21:00:10 | Re: cleanup patches for incremental backup |
Previous Message | Thomas Munro | 2024-03-14 20:58:09 | Re: BitmapHeapScan streaming read user and prelim refactoring |