Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE

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)

In response to

Browse pgsql-hackers by date

  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