| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
| Cc: | hlinnaka <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Subject: | Re: Multixid hindsight design |
| Date: | 2015-06-01 22:03:48 |
| Message-ID: | CAM-w4HPuAfnndB_nwbMrXqFGzyuLSmEHEs6r=LQeXYZraJSTmg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 1, 2015 at 8:53 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> What about prepared transactions? They can lock rows FOR SHARE that
> survive server restarts.
And they can make update chains that are still uncommitted after a restart.
I think we should think separately about what information we want to
store in the tuple ideally and only then worry about how to encode it
concisely as an optimization exercise. If you just grow every tuple by
64-bits would this scheme be trivial? Perhaps it would be worth
implementing that way first and then worrying about how to recuperate
that space later?
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2015-06-01 22:08:35 | Re: pg_xlog -> pg_xjournal? |
| Previous Message | David Steele | 2015-06-01 21:57:27 | Re: pg_xlog -> pg_xjournal? |