From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unify drop-by-OID functions |
Date: | 2020-05-05 17:28:58 |
Message-ID: | CA+TgmoYhgjHm6map2pAic=kh-YkEdVzgKsrbi+PmrqizaiKAYA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 5, 2020 at 1:22 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2020-05-05 17:42:17 | Re: Unify drop-by-OID functions |
Previous Message | Ranier Vilela | 2020-05-05 17:21:36 | Re: Unify drop-by-OID functions |