From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Logical decoding for operations on zheap tables |
Date: | 2019-01-12 11:32:29 |
Message-ID: | CAA4eK1K7LtbS8tRuL2owkvkYa9UKiOZqCWB0qtF_uovOs6zUJA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 4, 2019 at 9:01 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> On 2019-01-04 08:54:34 +0530, Amit Kapila wrote:
> > The only point for exposing a different tuple format via plugin was a
> > performance which I think can be addressed if we expose via slots. I
> > don't want to take up exposing slots instead of tuples for plugins as
> > part of this project and I think if we want to go with that, it is
> > better done as part of pluggable API?
>
> No, I don't think it makes sense to address this is as part of
> pluggable storage. That patchset is already way too invasive and
> large.
>
Fair enough. I think that for now (and maybe for the first version
that can be committed) we might want to use heap tuple format. There
will be some overhead but I think code-wise, things will be simpler.
I have prototyped it for Insert and Delete operations of zheap and the
only thing that is required are new decode functions, see the attached
patch. I have done very minimal testing of this patch as this is just
to show you and others the direction we are taking (w.r.t tuple
format) to support logical decoding in zheap.
Thanks for the feedback, further thoughts are welcome!
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
decode_zops_3.patch | application/octet-stream | 16.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2019-01-12 12:42:25 | Re: Pluggable Storage - Andres's take |
Previous Message | David Rowley | 2019-01-12 10:42:38 | Re: Delay locking partitions during query execution |