Re: Sequence Access Method WIP
Heikki Linnakangas <hlinnakangas@vmware.com>
From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Andres Freund <andres@2ndquadrant.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2013-11-18T12:06:25Z
Lists: 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
Commits
-
Add missing gss option to msvc config template
- 3063e7a84026 9.6.0 cited