On Tue, Apr 21, 2020 at 4:59 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Apr 21, 2020 at 7:58 AM Tom Lane wrote:
> >> Yeah, but that was for a security hole. I am doubtful that the
> >> severity of this problem is bad enough to justify jumping through
> >> similar hoops. Even i
Alexander Korotkov writes:
> On Tue, Apr 21, 2020 at 7:58 AM Tom Lane wrote:
>> Yeah, but that was for a security hole. I am doubtful that the
>> severity of this problem is bad enough to justify jumping through
>> similar hoops. Even if we fixed it and documented it, how many
>> users would bo
On Tue, Apr 21, 2020 at 7:58 AM Tom Lane wrote:
> Michael Paquier writes:
> > On Tue, Apr 21, 2020 at 02:44:45AM +0300, Alexander Korotkov wrote:
> >> As a bugfix, I think this should be backpatched. But this patch
> >> requires catalog change. Were similar cases there before? If so,
> >> how
On Tue, Apr 21, 2020 at 4:38 AM Michael Paquier wrote:
> On Tue, Apr 21, 2020 at 02:44:45AM +0300, Alexander Korotkov wrote:
> > Among all the joined tables, only "pg_index I" is expected to have
> > multiple rows associated with single relation. But we do sum() for
> > toast index "pg_index X" a
Michael Paquier writes:
> On Tue, Apr 21, 2020 at 02:44:45AM +0300, Alexander Korotkov wrote:
>> As a bugfix, I think this should be backpatched. But this patch
>> requires catalog change. Were similar cases there before? If so,
>> how did we resolve them?
> A backpatch can happen in such cas
On Tue, Apr 21, 2020 at 02:44:45AM +0300, Alexander Korotkov wrote:
> Among all the joined tables, only "pg_index I" is expected to have
> multiple rows associated with single relation. But we do sum() for
> toast index "pg_index X" as well. As the result, we multiply
> statistics for toast index
Hi!
It appears that definition of pg_statio_all_tables has bug.
CREATE VIEW pg_statio_all_tables AS
SELECT
C.oid AS relid,
N.nspname AS schemaname,
C.relname AS relname,
pg_stat_get_blocks_fetched(C.oid) -
pg_stat_get_blocks_
