Re: WIP: Avoid creation of the free space map for small tables
От | Michael Paquier |
---|---|
Тема | Re: WIP: Avoid creation of the free space map for small tables |
Дата | |
Msg-id | 20181104002649.GD1743@paquier.xyz обсуждение исходный текст |
Ответ на | Re: WIP: Avoid creation of the free space map for small tables (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: WIP: Avoid creation of the free space map for small tables
|
Список | pgsql-hackers |
On Fri, Nov 02, 2018 at 10:38:45AM -0400, Robert Haas wrote: > I think it's in evidence, in the form of several messages mentioning a > flag called try_every_block. > > Just checking the last page of the table doesn't sound like a good > idea to me. I think that will just lead to a lot of stupid bloat. It > seems likely that checking every page of the table is fine for npages > <= 3, and that would still be win in a very significant number of > cases, since lots of instances have many empty or tiny tables. I was > merely reacting to the suggestion that the approach should be used for > npages <= 32; that threshold sounds way too high. It seems to me that it would be costly for schemas which have one core table with a couple of records used in many joins with other queries. Imagine for example a core table like that: CREATE TABLE us_states (id serial, initials varchar(2)); INSERT INTO us_states VALUES (DEFAULT, 'CA'); If there is a workload where those initials need to be fetched a lot, this patch could cause a loss. It looks hard to me to put a straight number on when not having the FSM is better than having it because that could be environment-dependent, so there is an argument for making the default very low, still configurable? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: