Horton
Menu

Re: BUG #18016: REINDEX TABLE failure

Gurjeet Singh <gurjeet@singh.im>

View thread
From: Gurjeet Singh <gurjeet@singh.im>
To: Richard Veselý <richard.vesely@softea.sk>, Postgres Hackers <pgsql-hackers@postgresql.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>
Date: 2023-07-10T16:43:49Z
Lists: pgsql-bugs, pgsql-hackers 
On Sun, Jul 9, 2023 at 7:21 AM Richard Veselý <richard.vesely@softea.sk> wrote:
>
> ... there's no shortage of people that suffer from sluggish pg_dump/pg_restore cycle and I imagine there are any number of people that would be interested in improving bulk ingestion which is often a bottleneck for analytical workloads as you are well aware. What's the best place to discuss this topic further - pgsql-performance or someplace else?

(moved conversation to -hackers, and moved -bugs to BCC)

> I was dissatisfied with storage layer performance, especially during the initial database population, so I rewrote it for my use case. I'm done with the heap, but for the moment I still rely on PostgreSQL to build indexes,

It sounds like you've developed a method to speed up loading of
tables, and might have ideas/suggestions for speeding up CREATE
INDEX/REINDEX. The -hackers list feels like a place to discuss such
changes.

Best regards,
Gurjeet
http://Gurje.et

Commits

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

  1. Reindex toast before its main relation in reindex_relation()

  2. Fix comment in index.c

  3. Clean up a bug in sql/json items commit 66ea94e8e6

  4. Create a "relation mapping" infrastructure to support changing the relfilenodes