Re: Sequence Access Method WIP
От | Heikki Linnakangas |
---|---|
Тема | Re: Sequence Access Method WIP |
Дата | |
Msg-id | 528A02C1.1060308@vmware.com обсуждение исходный текст |
Ответ на | Re: Sequence Access Method WIP (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Sequence Access Method WIP
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: