On 24.11.2013 19:23, Simon Riggs wrote:
On 18 November 2013 07:06, Heikki Linnakangas <hlinnakan...@vmware.com> wrote:
On 18.11.2013 13:48, Simon Riggs wrote:

On 18 November 2013 07:50, Heikki Linnakangas <hlinnakan...@vmware.com>

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

I don't think the sequence AM should be in control of 'cached'. The
is done outside the AM. And log_cnt probably should be passed to the
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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to