On 24.11.2013 19:23, Simon Riggs wrote:
> 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()
The proposed changes to alloc() would still suffer from all the problems
that I complained about. Adding a new API alongside doesn't help with that.
- Heikki
