From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Greg Smith" <greg(at)2ndquadrant(dot)com>, <cedric(dot)villemain(dot)debian(at)gmail(dot)com> |
Cc: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Spread checkpoint sync |
Date: | 2011-02-07 18:38:34 |
Message-ID: | 4D4FE7CA020000250003A53C@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> As a larger statement on this topic, I'm never very excited about
> redesigning here starting from any point other than "saw a
> bottleneck doing <x> on a production system". There's a long list
> of such things already around waiting to be addressed, and I've
> never seen any good evidence of work related to hint bits being on
> it. Please correct me if you know of some--I suspect you do from
> the way you're brining this up.
There are occasional posts from those wondering why their read-only
queries are so slow after a bulk load, and why they are doing heavy
writes. (I remember when I posted about that, as a relative newbie,
and I know I've seen others.)
I think worst case is probably:
- Bulk load data.
- Analyze (but don't vacuum) the new data.
- Start a workload with a lot of small, concurrent random reads.
- Watch performance tank when the write cache gluts.
This pattern is why we've adopted a pretty strict rule in our shop
that we run VACUUM FREEZE ANALYZE between a bulk load and putting
the database back into production. It's probably a bigger issue for
those who can't do that.
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2011-02-07 18:58:30 | Re: More extension issues: ownership and search_path |
Previous Message | Peter Eisentraut | 2011-02-07 18:32:40 | Re: WIP: RangeTypes |