Re: BUG #18016: REINDEX TABLE failure
От | Gurjeet Singh |
---|---|
Тема | Re: BUG #18016: REINDEX TABLE failure |
Дата | |
Msg-id | CABwTF4UZB-cUSwfB7hQC2uosA2j0XBnL8JShB8oDuL-KBEdgJA@mail.gmail.com обсуждение исходный текст |
Ответы |
RE: BUG #18016: REINDEX TABLE failure
|
Список | 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 numberof people that would be interested in improving bulk ingestion which is often a bottleneck for analytical workloadsas 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 formy 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
В списке pgsql-hackers по дате отправления: