|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Jim Mlodgenski <jimmy76(at)gmail(dot)com>|
|Cc:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: mat views stats|
|Views:||Raw Message | Whole Thread | Download mbox|
Jim Mlodgenski <jimmy76(at)gmail(dot)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
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
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.
regards, tom lane
|Next Message||Peter Geoghegan||2017-03-18 22:22:43||Re: [PATCH] SortSupport for macaddr type|
|Previous Message||Peter Geoghegan||2017-03-18 21:54:03||Re: [PATCH] SortSupport for macaddr type|