Re: [SOLVED?] Re: Disk wait problem... not hardware...

Поиск
Список
Период
Сортировка
От Peter J. Holzer
Тема Re: [SOLVED?] Re: Disk wait problem... not hardware...
Дата
Msg-id 20231029151605.kijo6gumeen7jj26@hjp.at
обсуждение исходный текст
Ответ на [SOLVED?] Re: Disk wait problem... not hardware...  (pf@pfortin.com)
Ответы Re: [SOLVED?] Re: Disk wait problem... not hardware...
Список 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!"

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Paul Förster
Дата:
Сообщение: Re: pg_checksums?
Следующее
От: pf@pfortin.com
Дата:
Сообщение: Re: Disk wait problem... may not be hardware...