Alvaro Herrera writes:
> Tom Lane wrote:
>> I'm inclined to think that the don't-create-a-table-entry behavior in
>> pgstat_recv_vacuum and pgstat_recv_analyze should just be dropped.
> I think this business about supressing pgstat entries started because of
> autovacuum. I wasn't too fond of th
Tom Lane wrote:
> 4. At completion of ANALYZE, the regular tabstat machinery sends
> off a tabstat message for the table, because guess what, ANALYZE did a
> scan of that table, and there are t_blocks_fetched counts to report.
>
> 5. pgstat_recv_tabstat happily creates a table entry. (The pg_sta
On Wed, Sep 2, 2009 at 06:25, Tom Lane wrote:
> Magnus Hagander writes:
>>> and when i try to recover them via an analyze; (on all tables on the
>>> database) the result is nothing...
>>> i have to exexute the analyze commands twice to compute the statistics
>
>> pg_stat_* are not directly affecte
Magnus Hagander writes:
> On Tue, Sep 1, 2009 at 00:02, Jaime
> Casanova wrote:
>> when i issue an "immediate shutdown" the statistics on all tables
>> disappear...
> That is by design. Whenever the server goes into crash recovery on
> startup, it will clean out the statistics. Since the statist
On Tue, Sep 1, 2009 at 00:02, Jaime
Casanova wrote:
> Hi,
>
> pgsql 8.3.7 and 8.4.0
>
> when i issue an "immediate shutdown" the statistics on all tables disappear...
That is by design. Whenever the server goes into crash recovery on
startup, it will clean out the statistics. Since the statistics
Hi,
pgsql 8.3.7 and 8.4.0
when i issue an "immediate shutdown" the statistics on all tables disappear...
and when i try to recover them via an analyze; (on all tables on the
database) the result is nothing...
i have to exexute the analyze commands twice to compute the statistics
jd=# select rel
