Re: Unify drop-by-OID functions

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Unify drop-by-OID functions
Дата
Msg-id CAEudQAoLCPTBNzRyDy20GgpdRJYUpUCSwjbGR9Jkr20c8o93FA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Unify drop-by-OID functions  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Unify drop-by-OID functions  (Robert Haas <robertmhaas@gmail.com>)
Список 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Unify drop-by-OID functions
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: PG 13 release notes, first draft