Re: Postgres code for a query intermediate dataset

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Rohit Goyal <rhtgyl(dot)87(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgres code for a query intermediate dataset
Date: 2014-09-15 06:09:15
Message-ID: 5416828B.1030900@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14/09/14 20:43, Mark Kirkwood wrote:
> On 14/09/14 20:24, Atri Sharma wrote:
>>
>> How do you plan to do all that VACUUM does for this table then?
>>
>> It seems to me that you are saying to VACUUM that it need not be
>> concerned with table 'A' and you are assuming ownership of all the tasks
>> performed by VACUUM for this table. Seems pretty broken to me, not to
>> mention the performance degradations.
>>
>
> I think the whole point of such a modification is that nothing is done
> to such tables, as you want to see all the previous versions.
>
> Clearly this is less performant for standard workloads...but we are
> talking about non standard workloads surely...

To be fair with respect to what Atri is saying, I should have said
something like:

Clearly this is *horribly* less performant for standard workloads...etc :-)

Also there is the good point he raised about transaction xid wrap, so
some messing about with that part of VACUUM would be required too (it's
the little complications that all add up)!

The TRIGGER based approach is clearly a lot simpler! However for an
interest project to understand Postgres internals the other approach is
worthwhile.

Cheers

Mark

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-09-15 07:11:57 Re: orangutan seizes up during isolation-check
Previous Message Noah Misch 2014-09-15 04:51:14 Re: orangutan seizes up during isolation-check