On 2019-02-01 04:48, Michael Paquier wrote:
> On Thu, Jan 17, 2019 at 10:12:26AM +0900, Michael Paquier wrote:
>> Yes, something like that grows the memory and CPU usage rather
>> linearly:
>> CREATE TABLE tab (a int, b int GENERATED ALWAYS AS (a * 2) STORED);
>> INSERT INTO tab VALUES (generate_series(1,100000000));
>
> The latest patch set got plenty of feedback not addressed yet, so I am
> marking it as returned with feedback.
Here is an updated patch which should address the review comments in the
latest round.
My perspective on this patch is:
The stored generated column part is pretty solid. It can target PG12.
The virtual generated column part is still a bit iffy. I'm still
finding places here and there where virtual columns are not being
expanded correctly. Maybe it needs more refactoring. One big unsolved
issue is how the storage of such columns should work. Right now, they
are stored as nulls. That works fine, but what I suppose we'd really
want is to not store them at all. That, however, creates all kinds of
complications in the planner if target lists have non-matching lengths
or the resnos don't match up. I haven't figured out how to do this cleanly.
So I'm thinking if we can get agreement on the stored columns, I can cut
out the virtual column stuff for PG12. That should be fairly easy.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services