Re: Freeze avoidance of very large table.
От | Robert Haas |
---|---|
Тема | Re: Freeze avoidance of very large table. |
Дата | |
Msg-id | CA+TgmoZr=gOPPoUdfWZw+v6TLZ1zpvyS8_YNe0CS8vwQkrnxxw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Freeze avoidance of very large table. (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: Freeze avoidance of very large table.
|
Список | pgsql-hackers |
On Fri, Apr 24, 2015 at 4:09 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:>>> When I read that I think about something configurable at >>> relation-level.There are cases where you may want to have more >>> granularity of this information at block level by having the VM slots >>> to track less blocks than 32, and vice-versa. >> >> What are those cases? To me that sounds like making things >> complicated to no obvious benefit. > > Tables that get few/no dead tuples, like bulk insert tables. You'll have > large sections of blocks with the same visibility. I don't see any reason why that would require different granularity. > I suspect the added code to allow setting 1 bit for multiple pages without > having to lock all those pages simultaneously will probably outweigh making > this a reloption anyway. That's a completely unrelated issue. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: