Re: [Testperf-general] Re: ExclusiveLock
От | Simon Riggs |
---|---|
Тема | Re: [Testperf-general] Re: ExclusiveLock |
Дата | |
Msg-id | 1100818695.4113.10510.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: [Testperf-general] Re: ExclusiveLock (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [Testperf-general] Re: ExclusiveLock
|
Список | pgsql-hackers |
On Thu, 2004-11-18 at 22:51, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > The main problem on INSERTs is that it is usually the same few pages: > > the lead data block and the lead index block. There are ways of > > spreading the load out across an index, but I'm not sure what happens on > > the leading edge of the data relation, but I think it hits the same > > block each time. > > FSM does what it can to spread the insertion load across multiple pages, > but of course this is not going to help much unless your table has lots > of embedded free space. I think it would work pretty well on a table > with lots of update turnover, but not on an INSERT-only workload. OK, thats what I thought. So with a table with an INSERT-only workload, the FSM is always empty, so there only ever is one block that gets locked. That means we can't ever go faster than 1 CPU can go - any other CPUs will just wait for the block lock. [In Josh's case, 32 INSERT streams won't go significantly faster than about 4 streams, allowing for some overlap of other operations] Would it be possible to: when a new block is allocated from the relation file (rather than reused), we check the FSM - if it is empty, then we allocate 8 new blocks and add them all to the FSM. The next few INSERTers will then use the FSM blocks normally. Doing that will definitely speed up DBT-2 and many other workloads. Many tables have SERIAL defined, or use a monotonically increasing unique key. -- Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: