On 18 November 2013 07:06, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> 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.
I think the way to resolve this is to do both of these things, i.e. a
two level API
1. Implement SeqAM API at the most generic level. Add a nextval() call
as well as alloc()
2. Also implement the proposed changes to alloc()
So the SeqAM would implement either nextval() or alloc() but not both
global sequences as envisaged for BDR would use a special alloc() call.
I don't think that is too much work, but I want to do this just once...
Thoughts on exact next steps for implementation please?
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
