Re: Running PostgreSQL as fast as possible no matter the consequences
От | Jon Nelson |
---|---|
Тема | Re: Running PostgreSQL as fast as possible no matter the consequences |
Дата | |
Msg-id | AANLkTim5RaimYK15UdGvkgG_8KhCJdt_QguNLgxKh63Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Running PostgreSQL as fast as possible no matter the consequences (Guillaume Cottenceau <gc@mnc.ch>) |
Ответы |
Re: Running PostgreSQL as fast as possible no matter the consequences
|
Список | pgsql-performance |
On Fri, Nov 5, 2010 at 7:08 AM, Guillaume Cottenceau <gc@mnc.ch> wrote: > Marti Raudsepp <marti 'at' juffo.org> writes: > >> On Fri, Nov 5, 2010 at 13:32, A B <gentosaker@gmail.com> wrote: >>> I was just thinking about the case where I will have almost 100% >>> selects, but still needs something better than a plain key-value >>> storage so I can do some sql queries. >>> The server will just boot, load data, run, hopefully not crash but if >>> it would, just start over with load and run. >> >> If you want fast read queries then changing >> fsync/full_page_writes/synchronous_commit won't help you. > > That illustrates how knowing the reasoning of this particular > requests makes new suggestions worthwhile, while previous ones > are now seen as useless. I disagree that they are useless - the stated mechanism was "start, load data, and run". Changing the params above won't likely change much in the 'run' stage but would they help in the 'load' stage? -- Jon
В списке pgsql-performance по дате отправления: