Re: parametric block size?
От | Robert Haas |
---|---|
Тема | Re: parametric block size? |
Дата | |
Msg-id | CA+Tgmob=Ows1JcAx4ECziOQCEom6d5BguN8C7kUZP35YXZjiSw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: parametric block size? (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: parametric block size?
|
Список | pgsql-hackers |
On Tue, Jul 22, 2014 at 1:22 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Fabien wrote: >> ISTM that a desirable and reasonably simple to implement feature >> would be to be able to set the blocksize at "initdb" time, and >> "postgres" could use the value found in the database instead of a >> compile-time one. > > I think you will find it more difficult to implement than it seems at > first. For one thing, there are several macros that depend on the block > size and the algorithms involved cannot work with dynamic sizes; > consider MaxIndexTuplesPerPage which is used inPageIndexMultiDelete() > for instance. That value is used to allocate an array in the stack, > but that doesn't work if the array size is dynamic. (Actually it works > almost everywhere, but that feature is not in C89 and thus it fails on > Windows). That shouldn't be a problem, you say, just palloc() the array > -- except that that function is called within critical sections in some > places (e.g. _bt_delitems_vacuum) and you cannot use palloc there. There's a performance argument here as well. Static allocation is likely faster that palloc, and there are likely many other places where having things like BLCKSZ or MaxIndexTuplesPerPage as compile-time constants saves a few cycles. A 10% speedup is nice, but I wouldn't want to pay 1% for everybody to get back 10% people who are willing to fiddle with the block size. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: