Суббота, 7 января 2023, 20:23 +03:00 от Peter J. Holzer :
>On 2023-01-07 07:40:01 -0600, Ron wrote:
>> On 1/7/23 05:29, Peter J. Holzer wrote:
>> If I understood correctly, you have to delete about 3 million records
>> (worst case) from the main table each day. Including the other 8 tab
On 2023-01-07 07:40:01 -0600, Ron wrote:
> On 1/7/23 05:29, Peter J. Holzer wrote:
> If I understood correctly, you have to delete about 3 million records
> (worst case) from the main table each day. Including the other 8 tables
> those are 27 million DELETE queries each of which delete
On 1/7/23 05:29, Peter J. Holzer wrote:
[snip]
If I understood correctly, you have to delete about 3 million records
(worst case) from the main table each day. Including the other 8 tables
those are 27 million DELETE queries each of which deletes only a few
records. That's about 300 queries per s
On 2023-01-07 05:33:33 +, Ranjith Paliyath wrote:
>
> > This is because the deletion step is executed record
> > by record in main table, with its connected record(s)
> > delete executions in rest of tables?
>
> > I don't know if you have ON DE
Thank you very much again.
> So, with this approach, is the advantage like, manual
vacuuming worry may be set aside, because auto-vacuuming would deal with the
dead rows?
> Theoretically, manual vacuuming is never necessary. I'd occasionally
do manual vacuums (after p
On 1/6/23 08:27, Ranjith Paliyath wrote:
Thank you very much for the response.
> Can you do online purging?
> For example, get a list of the main table's primary keys to be deleted,
and
> then nibble away at them all day: in one transaction delete all the
records
> for one
Thank you very much for the response.
> Can you do online purging?
> For example, get a list of the main table's primary keys to be deleted,
and
> then nibble away at them all day: in one transaction delete all the
records
> for one logically related set of records. Do that N m
On 1/6/23 02:44, Ranjith Paliyath wrote:
Thank you for the details, experience shared and the suggestions.
Apologies for the delay in collecting the response for the queries.
(1)Are the tables tied together by FK?
- Overall there are 9 tables (sorry not 6 as mentioned originally) that are
be
Thank you for the details, experience shared and the suggestions.
Apologies for the delay in collecting the response for the queries.
(1)Are the tables tied together by FK?
- Overall there are 9 tables (sorry not 6 as mentioned originally) that are
being purged. Only 4 tables would be having FK
On 12/30/22 00:39, Ranjith Paliyath wrote:
Hi,
We have a PostgreSQL (slightly old version, something like - PostgreSQL 11.2
You know, of course, that you should update to the latest version. It's
quick and painless.
on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat
4.8
On Fri, Dec 30, 2022 at 12:09 PM Ranjith Paliyath
wrote:
> Hi,
>
> We have a PostgreSQL (slightly old version, something like - PostgreSQL
> 11.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat
> 4.8.5-36), 64-bit) production, where one particular table and its related 5
> t
months old data and vacuuming in production
Hi,
We have a PostgreSQL (slightly old version, something like - PostgreSQL 11.2 on
x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36),
64-bit) production, where one particular table and its related 5 tables need to
be purged of
Hi,
We have a PostgreSQL (slightly old version, something like - PostgreSQL 11.2 on
x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36),
64-bit) production, where one particular table and its related 5 tables need to
be purged of 3 months prior data. Each of these table
13 matches
Mail list logo
