Re: [HACKERS] Pluggable storage

On Thu, Jun 14, 2018 at 12:25 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> On Thu, Jun 14, 2018 at 1:50 AM, Haribabu Kommi
> <kommi(dot)haribabu(at)gmail(dot)com> wrote:
> >
> > On Fri, Apr 20, 2018 at 4:44 PM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com
> >
> > wrote:
> >
> > VACUUM:
> > Not much changes are done in this apart moving the Vacuum visibility
> > functions as part of the
> > storage. But idea for the Vacuum was with each access method can define
> how
> > it should perform.
> >
>
> We are planning to have a somewhat different mechanism for vacuum (for
> non-delete marked indexes), so if you can provide some details or
> discuss what you have in mind before implementation of same, that
> would be great.
>

OK. Thanks for your input. We will discuss the changes before proceed to
code.

Apart from the this, the pluggable storage API contains some re-factored
changes
along with API, some of the re-factored changes are

1. Change the snapshot satisfies type from function to an enum
2. Try to return always the palloced tuple instead of a pointer to buffer
(This change may have performance impact,so can be done later).
3. Perform a tuple visibility check at heap itself for the page mode
scenario also
4. New function ExecSlotCompare to compare two slots or tuple by storing it
a temp slot.
5. heap_fetch and heap_lock_tuple returns the palloced tuple, not the
pointer to the buffer
6. The index insertion logic decision is moved into heap itself(insert,
update), not in executor.
7. Split HeapscanDesc into two and remove it's usage outside heap of the
second split
8. Move the tuple traversing and providing the updated record to heap.

Is it fine to create these changes as separate patches and can go if the
changes are fine
and doesn't have any impact?

Any comments or additions or deletions to the above list?

Regards,
Haribabu Kommi
Fujitsu Australia