Re: [SOLVED?] Re: Disk wait problem... not hardware... - Mailing list pgsql-general

From Peter J. Holzer
Subject Re: [SOLVED?] Re: Disk wait problem... not hardware...
Date
Msg-id 20231029151605.kijo6gumeen7jj26@hjp.at
Whole thread Raw
In response to [SOLVED?] Re: Disk wait problem... not hardware...  (pf@pfortin.com)
Responses Re: [SOLVED?] Re: Disk wait problem... not hardware...  (pf@pfortin.com)
List pgsql-general
On 2023-10-29 09:21:46 -0400, pf@pfortin.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).

However, the table statistics contain an estimate for the number of
rows:

hjp=> select schemaname, relname, n_live_tup from pg_stat_user_tables order by 3 desc;
╔════════════╤═══════════════════════════╤════════════╗
║ schemaname │          relname          │ n_live_tup ║
╟────────────┼───────────────────────────┼────────────╢
║ public     │ ncvhis_2016_12_03         │    9999977 ║
║ public     │ random_test               │    1000000 ║
║ public     │ beislindex                │        351 ║
║ public     │ delivery                  │          6 ║
...


This is an estimate, not the actual count, so it might be wrong
(sometimes very wrong), but accessing it is fast and it might be good
enough for your purposes.

> 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?

        hp

--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

Attachment

pgsql-general by date:

Previous
From: Paul Förster
Date:
Subject: Re: pg_checksums?
Next
From: pf@pfortin.com
Date:
Subject: Re: Disk wait problem... may not be hardware...