| 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: | Whole Thread | Raw Message | 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 |