Re: Unify drop-by-OID functions
Ranier Vilela <ranier.vf@gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-05-05T17:42:17Z
Lists: pgsql-hackers
Em ter., 5 de mai. de 2020 às 14:29, Robert Haas <robertmhaas@gmail.com> escreveu: > On Tue, May 5, 2020 at 1:22 PM Ranier Vilela <ranier.vf@gmail.com> wrote: > > Ok, so the question. If (3) is not safe, obvious we shouldn't use, and > must call table_close, after systable_endscan. > > Now (1) and (2), I would have no hesitation in using it. > > I work with ERP, and throughout the time, the later, lock resources and > release them soon, the better, for the performance of the system as a whole. > > Even if it doesn't make much difference locally, using this process, > throughout the system, efficiency is noticeable. > > Apparently, it is more code, but it is less resources used and for less > time. > > And (2), if it is a case, frequently, no table would be blocked in this > function. > > Nobody here is going to question the concept that it's better to use > resources for less time rather than more, but the wisdom of sticking > to well-established coding patterns instead of inventing altogether > new ones is also well-understood. There are often good reasons why the > code is written in the way that it is, and it's important to > understand those before proposing to change things. > I see, the famous "cliché". regards, Ranier Vilela > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Commits
-
Unify drop-by-OID functions
- b1d32d3e3230 14.0 landed