Re: Parallel Inserts in CREATE TABLE AS
От | Amit Kapila |
---|---|
Тема | Re: Parallel Inserts in CREATE TABLE AS |
Дата | |
Msg-id | CAA4eK1KOKWgCe7a184FVW9V9LfhFnCRM3LttE7PY4ZQrKUn3mw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Inserts in CREATE TABLE AS (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Parallel Inserts in CREATE TABLE AS
|
Список | pgsql-hackers |
On Thu, May 27, 2021 at 10:27 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Thu, May 27, 2021 at 10:16 AM Bharath Rupireddy > <bharath.rupireddyforpostgres@gmail.com> wrote: > > > > On Thu, May 27, 2021 at 7:12 AM houzj.fnst@fujitsu.com > > <houzj.fnst@fujitsu.com> wrote: > > > I am afraid that the using the FSM seems not get a stable performance gain(at least on my machine), > > > I will take a deep look into this to figure out the difference. A naive idea it that the benefit that bulk extension > > > bring is not much greater than the cost in FSM. > > > Do you have some ideas on it ? > > > > I think, if we try what Amit and I said in [1], we should get some > > insights on whether the bulk relation extension is taking more time or > > the FSM lookup. I plan to share the testing patch adding the timings > > and the counters so that you can also test from your end. I hope > > that's fine with you. > > I think some other cause of contention on relation extension locks are > 1. CTAS is using a buffer strategy and due to that, it might need to > evict out the buffer frequently for getting the new block in. Maybe > we can identify by turning off the buffer strategy for CTAS and > increasing the shared buffer so that data fits in memory. > One more thing to ensure is whether all the workers are using the same access strategy? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: