From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
---|---|
To: | joshua(dot)yanovski(at)gmail(dot)com |
Cc: | kuntalghosh(dot)2007(at)gmail(dot)com, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, hlinnaka(at)iki(dot)fi, Jeff Davis <pgsql(at)j-davis(dot)com>, joe(dot)conway(at)crunchydata(dot)com |
Subject: | Re: In-place updates and serializable transactions |
Date: | 2018-11-14 21:39:45 |
Message-ID: | CACjxUsOPzRZsomSUU9rfba_Cy3yqT1txwaE9oV4_ztxCavysSQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 14, 2018 at 5:43 AM Joshua Yanovski
<joshua(dot)yanovski(at)gmail(dot)com> wrote:
> This is only a personal anecdote, but from my own experience with serializability, this sort of blind update isn't often contended in realistic workloads.
> So, if this only affects transactions with blind updates, I doubt it will cause much pain in real workloads (even though it might look bad in benchmarks which include a mix of blind writes and rmw operations). Particularly if it only happens if you explicitly opt into zheap storage.
I agree with all of that, but will be very interested in what
failures, if any, kick out from the "isolation" test set when all
tables are created using zheap. I added all the common failure
patterns I had seen to that set, and other have filled in some corner
cases I missed since then, so if everything there passes I would not
worry about it at all. If we do see some failures, we can take
another look to see whether any action is needed.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-11-14 21:41:27 | Re: Doc patch on psql output formats |
Previous Message | Robert Haas | 2018-11-14 21:36:49 | Re: Refactoring the checkpointer's fsync request queue |