Re: reducing random_page_cost from 4 to 2 to force index scan

Поиск
Список
Период
Сортировка
Искать
От
Vitalii Tymchyshyn
Тема
Re: reducing random_page_cost from 4 to 2 to force index scan
Дата
в 06:12:38
Msg-id
4DDB7682.9040402@gmail.com
Ответ на
Список
Дерево обсуждения
reducing random_page_cost from 4 to 2 to force index scan Sok Ann Yap <sokann@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: reducing random_page_cost from 4 to 2 to force index scan Merlin Moncure <mmoncure@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Robert Haas <robertmhaas@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Tom Lane <tgl@sss.pgh.pa.us>
Re: reducing random_page_cost from 4 to 2 to force index scan Robert Haas <robertmhaas@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Josh Berkus <josh@agliodbs.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Robert Haas <robertmhaas@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Josh Berkus <josh@agliodbs.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Robert Haas <robertmhaas@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Stuart Bishop <stuart@stuartbishop.net>
Re: reducing random_page_cost from 4 to 2 to force index scan Josh Berkus <josh@agliodbs.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Cédric Villemain <cedric.villemain.debian@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Craig Ringer <craig@postnewspapers.com.au>
Re: reducing random_page_cost from 4 to 2 to force index scan Greg Smith <greg@2ndquadrant.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Jesper Krogh <jesper@krogh.cc>
Re: reducing random_page_cost from 4 to 2 to force index scan Jesper Krogh <jesper@krogh.cc>
Re: reducing random_page_cost from 4 to 2 to force index scan Robert Haas <robertmhaas@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Tom Lane <tgl@sss.pgh.pa.us>
Re: reducing random_page_cost from 4 to 2 to force index scan Jim Nasby <jim@nasby.net>
Re: reducing random_page_cost from 4 to 2 to force index scan Greg Smith <greg@2ndquadrant.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Robert Haas <robertmhaas@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Jim Nasby <jim@nasby.net>
Re: reducing random_page_cost from 4 to 2 to force index scan Robert Haas <robertmhaas@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Josh Berkus <josh@agliodbs.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Robert Haas <robertmhaas@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Vitalii Tymchyshyn <tivv00@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Cédric Villemain <cedric.villemain.debian@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Jeff Janes <jeff.janes@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Tom Lane <tgl@sss.pgh.pa.us>
Re: reducing random_page_cost from 4 to 2 to force index scan Nathan Boley <npboley@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Tom Lane <tgl@sss.pgh.pa.us>
Re: reducing random_page_cost from 4 to 2 to force index scan Cédric Villemain <cedric.villemain.debian@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: reducing random_page_cost from 4 to 2 to force index scan Claudio Freire <klaussfreire@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Claudio Freire <klaussfreire@gmail.com>
Re: reducing random_page_cost from 4 to 2 to force index scan Sok Ann Yap <sokann@gmail.com>
Hello.

As of me, all this "hot" thing really looks like uncertain and dynamic 
enough.
Two things that I could directly use right now (and they are needed in 
pair) are:
1)Per-table/index/database bufferpools (split shared buffer into parts, 
allow to specify which index/table/database goes where)
2)Per-table/index cost settings

If I had this, I could allocate specific bufferpools for tables/indexes 
that MUST be hot in memory and set low costs for this specific tables.
P.S. Third thing, great to have to companion this two is "Load on 
startup" flag to automatically populate bufferpools with fast sequential 
read, but this can be easily emulated with a statement.

Best regards, Vitalii Tymchyshyn
В списке pgsql-performance по дате отправления
От: Craig Ringer
Дата:
От: Cédric Villemain
Дата:
FAQ