Re: Spread checkpoint sync

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Spread checkpoint sync
Дата
Msg-id 4D4FE7CA020000250003A53C@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Spread checkpoint sync  (Greg Smith <greg@2ndquadrant.com>)
Ответы Re: Spread checkpoint sync  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-hackers
Greg Smith <greg@2ndquadrant.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


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: WIP: RangeTypes
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: More extension issues: ownership and search_path