From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Avoid overhead open-close indexes (catalog updates) |
Date: | 2022-11-10 11:56:25 |
Message-ID: | CAEudQArpawTjkJUQoFwbQmVQtQi_xg1qBOW9NNb-FRrujZX5_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Em qui., 10 de nov. de 2022 às 05:16, Michael Paquier <michael(at)paquier(dot)xyz>
escreveu:
> On Thu, Sep 01, 2022 at 08:42:15AM -0300, Ranier Vilela wrote:
> > Let's wait for the patch to be accepted and committed, so we can try to
> > change it.
>
> FWIW, I think that this switch is a good idea for cases where we
> potentially update a bunch of tuples, especially based on what
> CatalogTupleInsert() tells in its top comment.
That's the idea.
> Each code path updated
> here needs a performance check to see if that's noticeable enough, but
> I can get behind the one of CopyStatistics(), at least.
>
For CopyStatistics() have performance checks.
>
> EnumValuesCreate() would matter less as this would require a large set
> of values in an enum, but perhaps ORMs would care and that should be
> measurable.
Have a list_length call, for a number of vals.
For 2 or more vals, it is already worth it, since
CatalogOpenIndexes/CatalogCloseIndexes will be called for each val.
> update_attstats() should lead to a measurable difference
> with a relation that has a bunch of attributes with few tuples.
>
Same here.
For 2 or more attributes, it is already worth it, since
CatalogOpenIndexes/CatalogCloseIndexes will be called for each.
DefineTSConfiguration() is less of an issue, still fine to change.
>
Ok.
AddRoleMems() should be equally measurable with a large DDL. As a
> whole, this looks pretty sane to me and a good idea to move on with.
>
One filter, only.
For all these functions, the only case that would possibly have no effect
would be in the case of changing a single tuple, in which case there would
be only one call CatalogOpenIndexes/CatalogCloseIndexes for both paths.
> I still need to check properly the code paths changed here, of
> course..
>
At least, the patch still applies properly.
regards,
Ranier Vilela
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2022-11-10 11:58:01 | Re: ExecRTCheckPerms() and many prunable partitions |
Previous Message | Simon Riggs | 2022-11-10 11:31:25 | Re: New docs chapter on Transaction Management and related changes |