Re: [SOLVED?] Re: Disk wait problem... not hardware...
От | Adrian Klaver |
---|---|
Тема | Re: [SOLVED?] Re: Disk wait problem... not hardware... |
Дата | |
Msg-id | 078dba52-de8b-46e3-a5d8-110145940b1a@aklaver.com обсуждение исходный текст |
Ответ на | Re: [SOLVED?] Re: Disk wait problem... not hardware... (pf@pfortin.com) |
Список | pgsql-general |
On 10/29/23 09:45, pf@pfortin.com wrote: > 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? 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.klaver@aklaver.com
В списке pgsql-general по дате отправления: