| From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
|---|---|
| To: | Olivier Gautherot <ogautherot(at)gautherot(dot)net> |
| Cc: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Enhancement Request |
| Date: | 2024-02-02 17:15:42 |
| Message-ID: | CANzqJaDqAsjbmFHOOjQSam6-tw-wJL_cQjD5HpMDEZww2WBRRg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Fri, Feb 2, 2024 at 10:02 AM Olivier Gautherot <ogautherot(at)gautherot(dot)net>
wrote:
>
>
> El vie, 2 feb 2024 14:54, Ron Johnson <ronljohnsonjr(at)gmail(dot)com> escribió:
>
>> On Fri, Feb 2, 2024 at 3:50 AM Olivier Gautherot <
>> ogautherot(at)gautherot(dot)net> wrote:
>>
>>>
>>>
>>> El jue, 1 feb 2024 2:35, Ron Johnson <ronljohnsonjr(at)gmail(dot)com> escribió:
>>>
>>>>
>>>> ...
>>>>
>>>
>>> Deleting large numbers of rows is a complex task with a lot of hidden
>>> issues (index management between other things). Adding a LIMIT paradigm
>>> will not simplify it in any way.
>>>
>>
>> Smaller "bites" are easier to manage than giant bites.
>>
>
> To some extent, yes. But when it comes to large quantities overall, you
> have to consider vacuum,
>
I set autovacuum=off on the relevant table before purging, then
vacuum-analyze before re-enabling autovacuum.
> and it's best to take the DB offline for that. It depends on your use case.
>
The objections seem to presume that DBAs are incompetent, don't test ahead
of time, and can't learn from their mistakes.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ravindranathan Rinilnath (Ext. - UniCredit) | 2024-02-02 17:53:27 | PgAdmin 4 tool - Filter and Limit selector greyed out |
| Previous Message | M Sarwar | 2024-02-02 15:53:06 | Re: Function is giving execution error from inside the procedure |