On Fri, Mar 17, 2017 at 2:30 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> I was wondering about doing an explicit test: if the XID being >> committed matches the one in the PGPROC, and nsubxids matches, and the >> actual list of XIDs matches, then apply the optimization. That could >> replace the logic that you've proposed to exclude non-commit cases, >> gxact cases, etc. and it seems fundamentally safer. But it might be a >> more expensive test, too, so I'm not sure. > > I think if the number of subxids is very small let us say under 5 or > so, then such a check might not matter, but otherwise it could be > expensive.
We could find out by testing it. We could also restrict the optimization to cases with just a few subxids, because if you've got a large number of subxids this optimization probably isn't buying much anyway. We're trying to avoid grabbing CLogControlLock to do a very small amount of work, but if you've got 10 or 20 subxids we're doing as much work anyway as the group update optimization is attempting to put into one batch. > So we have four ways to proceed: > 1. Have this optimization for subtransactions and make it safe by > having some additional conditions like check for recovery, explicit > check for if the actual transaction ids match with ids stored in proc. > 2. Have this optimization when there are no subtransactions. In this > case, we can have a very simple check for this optimization. > 3. Drop this patch and idea. > 4. Consider it for next version. > > I personally think second way is okay for this release as that looks > safe and gets us the maximum benefit we can achieve by this > optimization and then consider adding optimization for subtransactions > (first way) in the future version if we think it is safe and gives us > the benefit. > > Thoughts? I don't like #2 very much. Restricting it to a relatively small number of transactions - whatever we can show doesn't hurt performance - seems OK, but restriction it to the exactly-zero-subtransactions case seems poor. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
