Re: Why does ExecComputeStoredGenerated() form a heap tuple

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why does ExecComputeStoredGenerated() form a heap tuple
Date: 2019-04-23 08:23:23
Message-ID: 2f06f0ee-9f05-d6b7-d48f-841f4f69cc7e@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-04-01 11:23, Peter Eisentraut wrote:
> On 2019-03-31 04:57, Andres Freund wrote:
>> while rebasing the remaining tableam patches (luckily a pretty small set
>> now!), I had a few conflicts with ExecComputeStoredGenerated(). While
>> resolving I noticed:
>
> The core of that code was written a long time ago and perhaps hasn't
> caught up with all the refactoring going on. I'll look through your
> proposal and update the code.

The attached patch is based on your sketch. It's clearly better in the
long term not to rely on heap tuples here. But in testing this change
seems to make it slightly slower, certainly not a speedup as you were
apparently hoping for.

Test setup:

create table t0 (a int, b int);
insert into t0 select generate_series (1, 10000000); -- 10 million
\copy t0 (a) to 'test.dat';

-- for comparison, without generated column
truncate t0;
\copy t0 (a) from 'test.dat';

-- master
create table t1 (a int, b int generated always as (a * 2) stored);
truncate t1;
\copy t1 (a) from 'test.dat';

-- patched
truncate t1;
\copy t1 (a) from 'test.dat';

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
0001-Don-t-form-heap-tuple-in-ExecComputeStoredGenerated.patch text/plain 2.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2019-04-23 08:27:29 Re: Regression test PANICs with master-standby setup on same machine
Previous Message Jamison, Kirk 2019-04-23 08:20:00 RE: libpq debug log