|From:||Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>|
|Subject:||Re: TupleTableSlot abstraction|
|Views:||Raw Message | Whole Thread | Download mbox|
On Mon, Aug 6, 2018 at 10:15 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2018-08-06 10:08:24 +0530, Ashutosh Bapat wrote:
>> I think, I explained why getattr() needs to be a separate callback.
>> There's a reason why slot_getattr() more code than just calling
>> slot_getsomeattrs() and return the required one - the cases when the
>> requested attribute is NULL or is missing from a tuple. Depending
>> upon the tuple layout access to a simple attribute can be optimized
>> without spending cycles to extract attributes prior to that one.
>> Columnar store (I haven't seen Haribabu's patch), for example, stores
>> columns from multiple rows together and thus doesn't have a compact
>> version of tuple. In such cases extracting an individual attribute
>> directly is far cheaper than extracting all the previous attributes.
> OTOH, it means we continually access the null bitmap instead of just
Nope. The slot_getattr implementation in these patches as well as in
the current master return from tts_isnull if the array has the
> Your logic about not deforming columns in this case would hold for *any*
> deforming of previous columns as well. That's an optimization that we
> probably want to implement at some point (e.g. by building a bitmap of
> needed columns in the planner), but I don't think we should do it
> together with this already large patchset.
Agree about optimizing using a separate bitmap indicating validity of
a particular value.
>> Why should we force the storage API to extract all the attributes in
>> such a case?
> Because there's no need yet, and it complicates the API without
> corresponding benefit.
The earlier version of slot_getattr() was optimized to access a given
attribute. That must have been done for some reason. Leaving that
optimization aside for this work will cause regression in the cases
where that optimization matters.
The Postgres Database Company
|Next Message||Etsuro Fujita||2018-08-06 12:30:24||Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.|
|Previous Message||Yoshimi Ichiyanagi||2018-08-06 09:00:54||Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory|