Re: Speedup truncations of temporary relation forks

From: Daniil Davydov <3danissimo(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Speedup truncations of temporary relation forks
Date: 2025-06-02 06:23:41
Message-ID: CAJDiXghWKN6_uaQyTFVJkjV24dPsL5U9q8DgpB_u0GEoiPr8ww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Jun 2, 2025 at 11:14 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> > (I haven't figured out how to force postgres to
> > create a visibility map for temp table within the transaction block).
>
> I haven't tested this, but I think if you do bulk copy into a table
> which should mark pages all visible and after that if you delete some
> tuple from pages logically it should try to update the status to not
> all visible in vm?
>

I found reliable way to create all three forks :
begin;
create temp table test (id int) on commit delete rows;
copy test from 'data.csv' with (freeze);
insert into test select generate_series(2000000, 3000000);
delete from test where id % 500000 = 0;
commit;

--
Best regards,
Daniil Davydov

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-06-02 06:39:17 Re: Conflict detection for update_deleted in logical replication
Previous Message John Naylor 2025-06-02 06:01:30 Re: Batch TIDs lookup in ambulkdelete