On 18.11.2013 13:48, Simon Riggs wrote:
> On 18 November 2013 07:50, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
>
>> It doesn't go far enough, it's still too *low*-level. The sequence AM
>> implementation shouldn't need to have direct access to the buffer page at
>> all.
>
>> I don't think the sequence AM should be in control of 'cached'. The caching
>> is done outside the AM. And log_cnt probably should be passed to the _alloc
>> function directly as an argument, ie. the server code asks the AM to
>> allocate N new values in one call.
>
> I can't see what the rationale of your arguments is. All index Ams
> write WAL and control buffer locking etc..
Index AM's are completely responsible for the on-disk structure, while
with the proposed API, both the AM and the backend are intimately aware
of the on-disk representation. Such a shared responsibility is not a
good thing in an API. I would also be fine with going 100% to the index
AM direction, and remove all knowledge of the on-disk layout from the
backend code and move it into the AMs. Then you could actually implement
the discussed "store all sequences in a single file" change by writing a
new sequence AM for it.
- Heikki
