Re: TupleTableSlot abstraction - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TupleTableSlot abstraction
Date
Msg-id 9677.1538446918@sss.pgh.pa.us
Whole thread Raw
In response to Re: TupleTableSlot abstraction  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: TupleTableSlot abstraction  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> At Tue, 25 Sep 2018 16:45:09 -0700, Andres Freund <andres@anarazel.de> wrote in
<20180925234509.3hrrf6tmvy5tfith@alap3.anarazel.de>
>> On 2018-09-04 18:35:34 +0530, Amit Khandekar wrote:
>>> Pack the boolean members in TupleTableSlot into a 16 bit tts_flags.
>>> This reduces the size of TupleTableSlot since each bool member takes
>>> at least a byte on the platforms where bool is defined as a char.

> About bitfields, an advantage of it is debugger awareness. We
> don't need to look aside to the definitions of bitwise macros
> while using debugger. And the current code is preserved in
> appearance by using it.

FWIW, I would expect a change like this to be a net loss performance-wise
on most platforms.  Testing the contents of a byte-wide variable is pretty
cheap on any architecture invented later than ~ 1970.  Testing a bit,
though, requires a masking operation that is not free.  I am not seeing
how making TupleTableSlot a little smaller buys that back ... we don't
normally have that many active slots in a plan.

            regards, tom lane


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Subplan result caching
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Add SKIP LOCKED to VACUUM and ANALYZE