Re: [PATCH] pg_dump: lock tables in batches

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [PATCH] pg_dump: lock tables in batches
Дата
Msg-id 20221207170848.ophksk6dfri3qp2z@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: [PATCH] pg_dump: lock tables in batches  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] pg_dump: lock tables in batches  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2022-12-07 10:44:33 -0500, Tom Lane wrote:
> Aleksander Alekseev <aleksander@timescale.com> writes:
> > What he proposes is taking the locks in batches.
> 
> I have a strong sense of deja vu here.  I'm pretty sure I experimented
> with this idea last year and gave up on it.  I don't recall exactly
> why, but either it didn't show any meaningful performance improvement
> for me or there was some actual downside (that I'm not remembering
> right now).

> This would've been in the leadup to 989596152 and adjacent commits.
> I took a quick look through the threads cited in those commit messages
> and didn't find anything about it, but I think the discussion had
> gotten scattered across more threads.  Some digging in the archives
> could be useful.

IIRC the case we were looking at around 989596152 were CPU bound workloads,
rather than latency bound workloads. It'd not be surprising to have cases
where batching LOCKs helps latency, but not CPU bound.


I wonder if "manual" batching is the best answer. Alexander, have you
considered using libpq level pipelining?

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Error-safe user functions
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Error-safe user functions