Re: [HACKERS] mat views stats
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] mat views stats |
Дата | |
Msg-id | 9698.1489874267@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] mat views stats (Jim Mlodgenski <jimmy76@gmail.com>) |
Ответы |
Re: [HACKERS] mat views stats
|
Список | pgsql-hackers |
Jim Mlodgenski <jimmy76@gmail.com> writes: > After digging into things further, just making refresh report the stats > for what is it basically doing simplifies and solves it and it is > something we can back patch if that the consensus. See the attached > patch. I've pushed this into HEAD with one non-cosmetic change: the patch tried to pass a uint64 tuple count to pgstat_count_heap_insert(), whose argument was only declared as "int". This would go seriously wrong with matviews having more than INT_MAX rows, which hardly seems out of the question, so I changed pgstat_count_heap_insert() to take int64 instead. I don't think we can make that change in the back branches though. It seems too likely that third-party code might be calling pgstat_count_heap_insert(). We could possibly kluge around this to produce a safe-to-back-patch fix by doing something like pgstat_count_heap_insert(matviewRel, (int) Min(processed, INT_MAX)); But that seems pretty ugly. Given the lack of previous reports, I'm personally content to leave this unfixed in the back branches. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: