| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(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 11:48:22 |
| Message-ID: | CA+U5nMJ=fBW+ussJhTHQt5DxXRdSqP8OhuGOWKo=pSLrwghrfw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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..
Do you have a new use case that shows why changes should happen? We
can't just redesign things based upon arbitrary decisions about what
things should or should not be possible via the API.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2013-11-18 12:06:25 | Re: Sequence Access Method WIP |
| Previous Message | Rajeev rastogi | 2013-11-18 11:43:16 |