Horton

Re: In-placre persistance change of a relation

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: jakub.wartak@enterprisedb.com, stark.cfm@gmail.com, hlinnaka@iki.fi, barwick@gmail.com, jchampion@timescale.com, pryzby@telsasoft.com, tgl@sss.pgh.pa.us, rjuju123@gmail.com, jakub.wartak@tomtom.com, pgsql-hackers@lists.postgresql.org
Date: 2023-08-14T19:38:48Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_dump: Refactor getIndexes()

  2. Optimize DropRelFileNodesAllBuffers() for recovery.

Attachments

I think there are some good ideas here.  I started to take a look at the
patches, and I've attached a rebased version of the patch set.  Apologies
if I am repeating any discussions from upthread.

First, I tested the time difference in ALTER TABLE SET UNLOGGED/LOGGED with
the patch applied, and the results looked pretty impressive.

	before:
	postgres=# alter table test set unlogged;
	ALTER TABLE
	Time: 5108.071 ms (00:05.108)
	postgres=# alter table test set logged;
	ALTER TABLE
	Time: 6747.648 ms (00:06.748)

	after:
	postgres=# alter table test set unlogged;
	ALTER TABLE
	Time: 25.609 ms
	postgres=# alter table test set logged;
	ALTER TABLE
	Time: 1241.800 ms (00:01.242)

My first question is whether 0001 is a prerequisite to 0002.  I'm assuming
it is, but the reason wasn't immediately obvious to me.  If it's just
nice-to-have, perhaps we could simplify the patch set a bit.  I see that
Heikki had some general concerns with the marker file approach [0], so
perhaps it is at least worth brainstorming some alternatives if we _do_
need it.

[0] https://postgr.es/m/9827ebd3-de2e-fd52-4091-a568387b1fc2%40iki.fi

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com