Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbNRD-0004an-Ib for pgsql-docs@arkaria.postgresql.org; Mon, 04 Apr 2022 14:12:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nbNRB-0001KN-Gc for pgsql-docs@arkaria.postgresql.org; Mon, 04 Apr 2022 14:12:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbNRB-0001KE-7R for pgsql-docs@lists.postgresql.org; Mon, 04 Apr 2022 14:12:09 +0000 Received: from mail-yb1-xb2b.google.com ([2607:f8b0:4864:20::b2b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nbNR4-0004TU-EU for pgsql-docs@lists.postgresql.org; Mon, 04 Apr 2022 14:12:08 +0000 Received: by mail-yb1-xb2b.google.com with SMTP id x131so5281845ybe.11 for ; Mon, 04 Apr 2022 07:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X7fUCmnTiQ/iB+SCvLIEBi2KR5mUNzG99c3J3G0IHcA=; b=qyUK+en3Ghfb0PPi+ZC6mz1Qgd//O9hA29tL+fQb/m208cN9mN4HkvFczfJHH2ZGZh Sw9IV4r6tNGVfgFqCvH3Es4rY/TwzWP+Wm6xzkXQGh6aaTvAcmjMRNm+WohiWtjEZ0ZW nltuK2p4PO+9Jj0pjgbIH9+AcBrah/vIPsxWYVqOM6H0tMdiqRNX5jllDVcAkIVZuQaO GiEU0yN2PtsValsqw5QQZjhVY49G0PW8PC7KWNi1C17M8N8Tq/ipmQ5c9YI6Q5mzi6nm mVMGXuO7QlmG5Gl7OJcr7s/NGP/Ts+W46j04+CBBeFDZGOpo7br2TEFMZLnt2j9tLSIx 0uOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X7fUCmnTiQ/iB+SCvLIEBi2KR5mUNzG99c3J3G0IHcA=; b=YQeyg1USiK2/ZMCgIJNDe0ZHlF/B5TtRvFBlPAkyLdYN8nQzTyWOqwcf7AADvJitgP IcfHEAgVlDQTIrPbX13s0I9NMPhGbrsBgeNaurgHogzXPwRV5D3F6tBcf9uv/8J9ru6f zvr42O7JIeK1Ql+gysm/4P2aK3Z0ur00ums6QJ1ViWGlg+p9cisZFcyS4e/ucewFUlgu hRQDSFfJtJ+J36osMO3xWGZC6a3YpfqNibHfLQd8H//pA2rpOrL388moLq2AKDcJTyRW hH+8tVlCVcC88mZFVxGlkOzzB83vVD5SOEeF//eN4A8iPQn4aRKmLTqKVHl6uZjZ8hhE XCsg== X-Gm-Message-State: AOAM530SPCu2lXjJEE9Iq2AaDDBLMtSHWfSJaFMU6OEoNdw4LmdrfPKl GXwtIortBoS0bQ0zweEhYA4bz8mmWm/Y9U1umOyxsWDDtWk= X-Google-Smtp-Source: ABdhPJx5BJSZs+0JgVOeRXOouWeRKgwf1DThScZB1PgzWM8mJxeg2WZyaaCyMyBR71edyHzmIWsCsMoSZxp4DjPMmbg= X-Received: by 2002:a5b:145:0:b0:629:4ec6:bd74 with SMTP id c5-20020a5b0145000000b006294ec6bd74mr20296244ybp.572.1649081521549; Mon, 04 Apr 2022 07:12:01 -0700 (PDT) MIME-Version: 1.0 References: <1886050.1649080891@sss.pgh.pa.us> In-Reply-To: <1886050.1649080891@sss.pgh.pa.us> From: Kouber Saparev Date: Mon, 4 Apr 2022 17:11:45 +0300 Message-ID: Subject: Re: Indexes documentation bug To: Tom Lane Cc: pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000004c360405dbd4b6ed" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000004c360405dbd4b6ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My bad, yes indeed, the view is different. =D0=9D=D0=B0 =D0=BF=D0=BD, 4.04.2022 =D0=B3. =D0=B2 17:01 =D1=87. Tom Lane = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: > Kouber Saparev writes: > > I believe there is an error within this sentence in section > > > https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-= PG-STAT-USER-FUNCTIONS-VIEW > > > "Therefore, a bitmap scan increments the > > pg_stat_all_indexes.idx_tup_read count(s) > > for the index(es) it uses, and it increments the pg_stat_all_tables. > > idx_tup_fetch count for the table, but it does not affect > > pg_stat_all_indexes.idx_tup_fetch." > > > There is repeated mentioning of pg_stat_all_indexes.idx_tup_fetch while= I > > suppose one should read pg_stat_all_indexes.idx_scan instead the secon= d > > time. I.e. bitmap scans do not increment idx_scan. > > Um ... you did notice that the mentions of idx_tup_fetch apply to two > different views, pg_stat_all_tables vs pg_stat_all_indexes? > > regards, tom lane > --0000000000004c360405dbd4b6ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My bad, yes indeed, the view is different.

=D0=9D=D0=B0 =D0= =BF=D0=BD, 4.04.2022 =D0=B3. =D0=B2 17:01 =D1=87. Tom Lane <tgl@sss.pgh.pa.us> =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0:
Ko= uber Saparev <koub= er@gmail.com> writes:
> I believe there is an error within this sentence in section
> https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORI= NG-PG-STAT-USER-FUNCTIONS-VIEW

> "Therefore, a bitmap scan increments the
> pg_stat_all_indexes.idx_tup_read count(s)
> for the index(es) it uses, and it increments the pg_stat_all_tables. > idx_tup_fetch count for the table, but it does not affect
> pg_stat_all_indexes.idx_tup_fetch."

> There is repeated mentioning of pg_stat_all_indexes.idx_tup_fetch whil= e I
> suppose one should read=C2=A0 pg_stat_all_indexes.idx_scan instead the= second
> time. I.e. bitmap scans do not increment idx_scan.

Um ... you did notice that the mentions of idx_tup_fetch apply to two
different views, pg_stat_all_tables vs pg_stat_all_indexes?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 regards, tom lane
--0000000000004c360405dbd4b6ed--