Horton

Re: executor relation handling

Jesper Pedersen <jesper.pedersen@redhat.com>

View thread View on postgr.es
From: Jesper Pedersen <jesper.pedersen@redhat.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, David Rowley <david.rowley@2ndquadrant.com>
Cc: Amit Langote <amitlangote09@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2018-09-28T13:51:47Z
Lists: pgsql-hackers 
Hi,

On 9/28/18 4:58 AM, Amit Langote wrote:
>>> Okay, I've revised the text in the attached updated patch.
>>
>> Meh, I just noticed that the WARNING text claims "InitPlan" is the
>> function name. I think it's best to get rid of that. It's pretty much
>> redundant anyway if you do: \set VERBOSITY verbose
> 
> Oops, good catch that one.  Removed "InitPlan: " from the message in the
> attached.
> 

I have looked at the patch (v9), and have no further comments. I can 
confirm a speedup in the SELECT FOR SHARE case.

Thanks for working on this !

Best regards,
  Jesper

Commits

  1. Avoid O(N^2) cost in ExecFindRowMark().

  2. Remove some unnecessary fields from Plan trees.

  3. Restore sane locking behavior during parallel query.

  4. Remove more redundant relation locking during executor startup.

  5. In the executor, use an array of pointers to access the rangetable.

  6. Centralize executor's opening/closing of Relations for rangetable entries.

  7. Change executor to just Assert that table locks were already obtained.

  8. Change rewriter/planner/executor/plancache to depend on RTE rellockmode.

  9. Add assertions that we hold some relevant lock during relation open.

  10. Create an RTE field to record the query's lock mode for each relation.