From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sequence Access Method WIP |
Date: | 2013-11-18 12:06:25 |
Message-ID: | 528A02C1.1060308@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 18.11.2013 13:48, Simon Riggs wrote:
> On 18 November 2013 07:50, Heikki Linnakangas <hlinnakangas(at)vmware(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-11-18 12:19:58 | Re: REINDEX CONCURRENTLY 2.0 |
Previous Message | Simon Riggs | 2013-11-18 11:48:22 | Re: Sequence Access Method WIP |