| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Sequence Access Method WIP |
| Date: | 2014-11-08 02:10:41 |
| Message-ID: | CA+TgmoYA5Ud4qd0zXCjdwrz=ohve25cfk8n_SOVr_6SnmuxKAA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 7, 2014 at 7:26 PM, Petr Jelinek <petr(at)2ndquadrant(dot)com> wrote:
>> My main problem is actually not with having tuple per-seqAM, but more
>> with the fact that Heikki does not want to have last_value as compulsory
>> column/parameter. How is the new AM then supposed to know where to pick
>> up and if it even can pick up?
That seems pretty well impossible to know anyway. If the pluggable AM
was handing out values at random or in some unpredictable fashion,
there may be no well-defined point where it's safe for the default AM
to resume. Granted, in the case of replication, it probably is
possible, and maybe that's important enough to be worth catering to.
> And obviously, once the last_value is part of the compulsory columns we
> again have to WAL log all the time for the use-case which Heikki is using as
> model, so it does not help there (just to clear what my point was about).
But I don't know what to do about that. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-11-08 02:16:45 | Re: TODO request: log_long_transaction |
| Previous Message | Robert Haas | 2014-11-08 02:05:09 | Re: tracking commit timestamps |