From: | Vitalii Tymchyshyn <tivv00(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "david(at)lang(dot)hm" <david(at)lang(dot)hm>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Slow count(*) again... |
Date: | 2011-02-03 09:54:49 |
Message-ID: | 4D4A7B69.2020704@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
02.02.11 20:32, Robert Haas написав(ла):
>
> Yeah. Any kind of bulk load into an empty table can be a problem,
> even if it's not temporary. When you load a bunch of data and then
> immediately plan a query against it, autoanalyze hasn't had a chance
> to do its thing yet, so sometimes you get a lousy plan.
May be introducing something like 'AutoAnalyze' threshold will help? I
mean that any insert/update/delete statement that changes more then x%
of table (and no less then y records) must do analyze right after it was
finished.
Defaults like x=50 y=10000 should be quite good as for me.
Best regards, Vitalii Tymchyshyn
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2011-02-03 10:07:20 | Typo in create user mapping docs page |
Previous Message | Žiga Kranjec | 2011-02-03 09:05:22 | Re: ALTER EXTENSION UPGRADE, v3 |
From | Date | Subject | |
---|---|---|---|
Next Message | david | 2011-02-03 10:11:58 | Re: [HACKERS] Slow count(*) again... |
Previous Message | Glyn Astill | 2011-02-03 09:54:31 | Re: Which RAID Controllers to pick/avoid? |