On Tue, Jun 11, 2019 at 12:32 PM Andres Freund wrote:
> Yea, I think there's plenty reasons to want to do something different
> than what we're doing. But I'd like to see a concrete proposal before
> building API for it...
I wasn't intending to propose that you should. We're just in the
Hi,
On 2019-06-11 11:59:36 -0400, Robert Haas wrote:
> On Tue, Jun 11, 2019 at 11:47 AM Alvaro Herrera
> wrote:
> > On 2019-Apr-10, Alexander Korotkov wrote:
> > > Alternative idea is to have MVCC-aware indexes. This approach looks
> > > more attractive for me. In this approach you basically
On Tue, Jun 11, 2019 at 8:59 AM Robert Haas wrote:
> I don't think that including visibility information in indexes is a
> bad idea; we've thought about making zheap do this someday. But I
> think that we need to use some more sophisticated approach involving,
> maybe, undo pointers, or some
On Tue, Jun 11, 2019 at 11:47 AM Alvaro Herrera
wrote:
> On 2019-Apr-10, Alexander Korotkov wrote:
> > Alternative idea is to have MVCC-aware indexes. This approach looks
> > more attractive for me. In this approach you basically need xmin,
> > xmax fields in index tuples.
>
> "We liked
On 2019-Apr-10, Alexander Korotkov wrote:
> Alternative idea is to have MVCC-aware indexes. This approach looks
> more attractive for me. In this approach you basically need xmin,
> xmax fields in index tuples.
"We liked freezing xmin so much that we had to introduce freezing for
xmax" --
On Wed, 10 Apr 2019 at 18:14, Alexander Korotkov
wrote:
> Alternative idea is to have MVCC-aware indexes. This approach looks
> more attractive for me. In this approach you basically need xmin,
> xmax fields in index tuples. On insertion of index tuple you fill
> it's xmin. On update,
> On Wed, Apr 17, 2019 at 10:25 PM Andres Freund wrote:
>
> I assume you're aware, but it's probably not going to be applied for 12...
Sure, the patch was mostly to express more clearly what I was thinking about :)
> I think most of the read-only stuff just needs to be non-optional, and most
>
Hi!
On 2019-04-17 22:02:24 +0200, Dmitry Dolgov wrote:
> > On Fri, Apr 5, 2019 at 10:25 PM Andres Freund wrote:
> >
> > A second set of limitations is around making more of tableam
> > optional. Right now it e.g. is not possible to have an AM that doesn't
> > implement insert/update/delete.
> On Fri, Apr 5, 2019 at 10:25 PM Andres Freund wrote:
>
> A second set of limitations is around making more of tableam
> optional. Right now it e.g. is not possible to have an AM that doesn't
> implement insert/update/delete. Obviously an AM can just throw an error
> in the relevant callbacks,
On Wed, Apr 10, 2019 at 8:32 PM Andres Freund wrote:
> On 2019-04-10 20:14:17 +0300, Alexander Korotkov wrote:
> > Your explanation of existing limitations looks very good and
> > convincing. But I think there is one you didn't mention. We require
> > new table AMs to basically save old
On Wed, Apr 10, 2019 at 8:32 PM Andres Freund wrote:
> On 2019-04-10 20:14:17 +0300, Alexander Korotkov wrote:
> > Your explanation of existing limitations looks very good and
> > convincing. But I think there is one you didn't mention. We require
> > new table AMs to basically save old
Hi,
On 2019-04-10 20:14:17 +0300, Alexander Korotkov wrote:
> Your explanation of existing limitations looks very good and
> convincing. But I think there is one you didn't mention. We require
> new table AMs to basically save old "contract" between heap and
> indexes. We have "all or nothing"
On Fri, Apr 5, 2019 at 11:25 PM Andres Freund wrote:
> I want to thank Haribabu, Alvaro, Alexander, David, Dmitry and all the
> others that collaborated on making tableam happen. It was/is a huge
> project.
Thank you so much for bringing this project to commit! Excellent work!
Your explanation
Hi,
On 2019-04-09 11:17:29 +0200, Dmitry Dolgov wrote:
> I'm also curious about that. As far as I can see the main objection against
> that was that in this case the recovery process will depend on an extension,
> which could violate reliability.
I don't think that's a primary concern - although
On Tue, Apr 9, 2019 at 2:12 PM Haribabu Kommi wrote:
> I got the same doubt when i looked into some of the UNDO patches
> where it tries to modify the core code to add UNDO specific WAL types.
> Different AM's may need different set of operations to be WAL logged,
> so it may be better for the
> On Tue, Apr 9, 2019 at 4:12 AM Haribabu Kommi
> wrote:
>
> On Sat, Apr 6, 2019 at 7:25 AM Andres Freund wrote:
>>
>> With regards to storing the rows themselves, the second biggest
>> limitation is a limitation that is not actually a part of tableam
>> itself: WAL. Many tableam's would want
On 08/04/2019 19:38, Andres Freund wrote:
On 2019-04-08 14:53:53 +0300, Heikki Linnakangas wrote:
On 05/04/2019 23:25, Andres Freund wrote:
- the (optional) bitmap heap scan API - that's fairly intrinsically
block based. An AM could just internally subdivide TIDs in a different
way,
On Sat, Apr 6, 2019 at 7:25 AM Andres Freund wrote:
> Hi,
>
> In this email I want to give a brief status update of the table access
> method work - I assume that most of you sensibly haven't followed it
> into all nooks and crannies.
>
> I want to thank Haribabu, Alv
Hi
On 2019-04-08 14:53:53 +0300, Heikki Linnakangas wrote:
> On 05/04/2019 23:25, Andres Freund wrote:
> > - the (optional) bitmap heap scan API - that's fairly intrinsically
> >block based. An AM could just internally subdivide TIDs in a different
> >way, but I don't think a bitmap scan
On 05/04/2019 23:25, Andres Freund wrote:
I think what's in v12 - I don't know of any non-cleanup / bugfix work
pending for 12 - is a pretty reasonable initial set of features.
Hooray!
- the (optional) bitmap heap scan API - that's fairly intrinsically
block based. An AM could just
Hi,
In this email I want to give a brief status update of the table access
method work - I assume that most of you sensibly haven't followed it
into all nooks and crannies.
I want to thank Haribabu, Alvaro, Alexander, David, Dmitry and all the
others that collaborated on making tableam happen
21 matches
Mail list logo
