Re: [HACKERS] Bug? relpages, reltuples resets to zero
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] Bug? relpages, reltuples resets to zero |
Дата | |
Msg-id | m0zWejK-000EBPC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Bug? relpages, reltuples resets to zero (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Bug? relpages, reltuples resets to zero
|
Список | pgsql-hackers |
Bruce Momjian wrote: > I have seen the optimizer stop using indexes, but could never reproduce > it, and hoped my mega-patch would have fix it. > > My only guess is that vacuum has changed the buffer cache copy of the > pg_class tuple, but did not mark it as dirty, so it was not written back > out when removed from the buffer cache. When reloaded after the query, > the buffer cache is loaded from the disk copy, and the disk copy has > zeros, because the vacuum copy was not written to disk. > > The active code is in vacuum.c::vc_updstats: Your guess was right, thanks. But your solution does not work :-( I found a way to easily reproduce the error. Run VACUUM Restart postmaster -> relpages and reltuples gone I think the simple way of modifying the tuple in the page does not work. I found that catalog/index.c does the same for relpages and reltuples in UpdateStats(). Calling UpdateStats() after vc_updstats() as a quick hack solved the problem. I'm now cvsup'ing, then I'll modify vacuum.c to do it the same way as index.c does it. I don't know if calling UpdateStats() instead is really a good idea, because vacuum potentially truncates files and UpdateStats() does RelationGetNumberOfBlocks() instead of getting it by argument. This might be wrong at that time. Let's see what happens when vacuum does it harder. Later, Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: