| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | fast defaults in heap_getattr vs heap_deform_tuple |
| Date: | 2019-02-01 16:24:04 |
| Message-ID: | 20190201162404.onngi77f26baem4g@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
While working on the patch to slotify trigger.c I got somewhat confused
by the need to expand tuples in trigger.c:
static HeapTuple
GetTupleForTrigger(EState *estate,
EPQState *epqstate,
ResultRelInfo *relinfo,
ItemPointer tid,
LockTupleMode lockmode,
TupleTableSlot **newSlot)
{
...
if (HeapTupleHeaderGetNatts(tuple.t_data) < relation->rd_att->natts)
result = heap_expand_tuple(&tuple, relation->rd_att);
else
result = heap_copytuple(&tuple);
ReleaseBuffer(buffer);
There's no explanation why GetTupleForTrigger() needs expanding tuples,
but most other parts of postgres don't. Normally deforming ought to take
care of expanding missing attrs.
As far as I can tell, the reason that it's needed is that heap_gettar()
wasn't updated along the rest of the functions. heap_deform_tuple(),
heap_attisnull() etc look for missing attrs, but heap_getattr() doesn't.
That, to me, makes no sense. The reason that we see a difference in
regression test output is that composite_to_json() uses heap_getattr(),
if it used heap_deform_tuple (which'd be considerably faster), we'd get
the default value.
Am I missing something?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Steele | 2019-02-01 17:14:19 | Re: initdb --allow-group-access behaviour in windows |
| Previous Message | Matwey V. Kornilov | 2019-02-01 16:08:00 | [PATCH 3/3] Add initial support for spgist quadtree @<(point,circle) operator |