From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | pf(at)pfortin(dot)com, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: [SOLVED?] Re: Disk wait problem... not hardware... |
Date: | 2023-10-29 17:03:14 |
Message-ID: | 078dba52-de8b-46e3-a5d8-110145940b1a@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 10/29/23 09:45, pf(at)pfortin(dot)com wrote:
> On Sun, 29 Oct 2023 16:16:05 +0100 Peter J. Holzer wrote:
>
>> On 2023-10-29 09:21:46 -0400, pf(at)pfortin(dot)com wrote:
>>> These are all static tables. Does PG maintain a table row count so as to
>>> avoid having to count each time?
>>
>> No. To count the rows in a table, Postgres has to actually read the
>> whole table (or an index, if a suitable index (e.g. a primary key)
>> exists).
>
> Am I correct to assume count(fieldname) would only load that column for
> counting? In other words: we should be specific (avoid "*") in general?
Read:
https://wiki.postgresql.org/wiki/Slow_Counting
>>> WB is setup to:
>>> * autoload table row count
>>> * autoload table data (restricted with LIMIT)
>>
>> Maybe WB can be set up to get n_live_tup instead of the real row count?
So basically you are dealing with a client issue.
>
> It appears this is hard-coded [on/off only]; but I thought I saw the WB
> author post on this list recently...
>
>> hp
>>
>
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Förster | 2023-10-29 17:57:15 | Re: pg_checksums? |
Previous Message | Ron | 2023-10-29 16:51:32 | Re: [SOLVED?] Re: Disk wait problem... not hardware... |