Hi,
> * The previous coding allowed for a fast path to access the last
> unowned relation, which this patch removes. It seems a good idea to
> cache the last unowned relation, or if not explain why the comment
> that says why it worked that way is no longer true.
>
> * We should only create the hash table when needed, i.e. on or after
> when we add an unowned relation, since that is not a typical case.
>
> * The hash table is sized at 400 elements and will grow from there.
> The comments in dynahash say "An overly large nelem will penalize
> hash_seq_search speed without buying much." so this makes your patch
> suitable for the bulk case but likely to perform worse for fewer
> elements. So I'm guessing that you picked 400 because that's what the
> parameter is set to for the smgr relation table rather than because
> this has had good consideration.
I thought abount improving the above problems.
But I have no good ideas to improve every case.
Do you have any good ideas?
I suggest to apply this modification only for the startup process.
This is because the startup process has many unowned SMgrRelation objects.
In XLOG replay, statup process create fake relcaches.
Fake relcaches create unowned SMgrRelation objects.
So startup process has more unowned SMgrRelation objects than any other process.
Of cource, it is necessary to think about the problems such as hash size.
Do you think about it.
Regards, Takashi Tokuda
