Re: Freeze avoidance of very large table.
От | Jim Nasby |
---|---|
Тема | Re: Freeze avoidance of very large table. |
Дата | |
Msg-id | 55D50E56.4020400@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Freeze avoidance of very large table. (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Freeze avoidance of very large table.
|
Список | pgsql-hackers |
On 8/19/15 2:56 AM, Masahiko Sawada wrote: > The currently regression test for VM is that we just compare between > the total number of all-visible and all-frozen in VM before and after > VACUUM, and don't check particular a bit in VM. > we could substitute it to the ANALYZE command with enough sampling > number and checking pg_class.relallvisible and pg_class.relallfrozen. I think this is another indication that we need more than just pg_regress... > So another way is that diagnostic function for VM is put into > something contrib (pg_freespacemap or pageinspect), and if we want to > use such function in production, we can install such extension as in > the past. pg_buffercache is very useful as a performance monitoring tool, and I view being able to pull statistics about the VM and FM the same way. I'd like to see us providing more performance information by default, not less. I think things like pageinspect are very different; I really can't see any use for those beyond debugging (and debugging by an expert at that). -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: