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

Поиск
Список
Период
Сортировка
От pf@pfortin.com
Тема Re: [SOLVED?] Re: Disk wait problem... not hardware...
Дата
Msg-id 20231029124508.71a8ce22.pfortin@pfortin.com
обсуждение исходный текст
Ответ на Re: [SOLVED?] Re: Disk wait problem... not hardware...  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Ответы Re: [SOLVED?] Re: Disk wait problem... not hardware...
Re: [SOLVED?] Re: Disk wait problem... not hardware...
Re: [SOLVED?] Re: Disk wait problem... not hardware...
Список pgsql-general
On Sun, 29 Oct 2023 16:16:05 +0100 Peter J. Holzer wrote:

>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).

Am I correct to assume count(fieldname) would only load that column for
counting?  In other words: we should be specific (avoid "*") in general?

>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 ║
>...

Are there prerequisites for this query?
Every (264) n_live_tup returned was zero...  though, VERY fast.. :)

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

Thanks for sharing...  We're learning fast... :)

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

It appears this is hard-coded [on/off only]; but I thought I saw the WB
author post on this list recently...

>        hp
>



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

Предыдущее
От: "Peter J. Holzer"
Дата:
Сообщение: Re: pg_checksums?
Следующее
От: Ron
Дата:
Сообщение: Re: [SOLVED?] Re: Disk wait problem... not hardware...