Re: WIP: Avoid creation of the free space map for small tables
От | Robert Haas |
---|---|
Тема | Re: WIP: Avoid creation of the free space map for small tables |
Дата | |
Msg-id | CA+TgmoYzg3zH-VdPAxT6SZGtz5P9TXU6kk58_z-0gQhoX_DUbg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: Avoid creation of the free space map for small tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP: Avoid creation of the free space map for small tables
Re: WIP: Avoid creation of the free space map for small tables Re: WIP: Avoid creation of the free space map for small tables |
Список | pgsql-hackers |
On Fri, Nov 2, 2018 at 10:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > That's not what I'm saying. If we don't have the FSM, we have to > > check every page of the table. If there's a workload where that > > happens a lot on a table that is just under the size threshold for > > creating the FSM, then it's likely to be a worst case for this patch. > > Hmm, you're assuming something not in evidence: why would that be the > algorithm? 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: