Re: [PATCH] Small optimization across postgres (remove strlenduplicate usage) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: [PATCH] Small optimization across postgres (remove strlenduplicate usage)
Date
Msg-id CAEudQArFqf6r23DcuPKah5XQUY4HZHJ8aUqDbFWzdWPu5UfeOw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Small optimization across postgres (remove strlenduplicate usage)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: [PATCH] Small optimization across postgres (remove strlenduplicate usage)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: [PATCH] Small optimization across postgres (remove strlenduplicate usage)  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
Em dom., 19 de abr. de 2020 às 16:33, Tomas Vondra <tomas.vondra@2ndquadrant.com> escreveu:
On Sun, Apr 19, 2020 at 11:24:38AM -0300, Ranier Vilela wrote:
>Hi,
>strlen it is one of the low fruits that can be harvested.
>What is your opinion?
>

That assumes this actually affects/improves performance, without any
measurements proving that. Considering large number of the places you
modified are related to DDL (CreateComment, ChooseIndexColumnNames, ...)
or stuff that runs only once or infrequently (like the changes in
PostmasterMain or libpqrcv_get_senderinfo). Likewise, it seems entirely
pointless to worry about strlen() overhead e.g. in fsync_parent_path
which is probably dominated by I/O.
With code as interconnected as postgres, it is difficult to say that a function, which calls strlen, repeatedly, would not have any gain.
Regarding the functions, I was just being consistent, trying to remove all occurrences, even where, there is very little gain.
 

Maybe there are places where this would help, but I don't see a reason
to just throw away all strlen calls and replace them with something
clearly less convenient and possibly more error-prone (I'd expect quite
a few off-by-one mistakes with this).
Yes, always, it is prone to errors, but for the most part, they are safe changes.
It passes all 199 tests, of course it has not been tested in a real production environment.
Perhaps the time is not the best, the end of the cycle, but, once done, I believe it would be a good harvest.

 Thank you for comment.

regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: HEAPDEBUGALL is broken
Next
From: Alvaro Herrera
Date:
Subject: Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables