Re: Disable WAL completely - Performance and Persistency research
От | Jeff Janes |
---|---|
Тема | Re: Disable WAL completely - Performance and Persistency research |
Дата | |
Msg-id | CAMkU=1yNHkAtVUf7pzD_tw6Bk90qxzS=UpOjOjbghtgP8C-dKQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Disable WAL completely - Performance and Persistency research (Netanel Katzburg <netanel10k@gmail.com>) |
Ответы |
Re: Disable WAL completely - Performance and Persistency research
|
Список | pgsql-hackers |
On Thu, Jul 7, 2016 at 1:01 AM, Netanel Katzburg <netanel10k@gmail.com> wrote: > Hi All, > > As part of my masters at TAU, I'm currently conducting some research > regarding new persistent memory technology. > I'm using PG for this research and would like to better understand some of > the performance bottlenecks. > For this reason I'm trying to disable the WAL completely, using some hacks > on the source code and compiling my own version. > > So what I'm actually looking for, is some guidance about a simple way to: > > 1. Disable the WAL by not writing anything to the xlog directory. I don't > care about recovery/fault tolerance or PITR/ replication etc at the moment. > I'm aware that the WAL and checkpoint are bind in many ways and are crucial > for PG core features. > I tried changing the status of all tables to "unlogged" tables by changing > RelationNeedsWAL MACRO, as well as "needs_wal" parameter at storage.c. > But, got no performance benefit, so I guess this was the wrong place to > change. > > 2. Cancel the locking around WAL files - I don't care about corrupted files > at the moment, I just want to see what is the maximum performance benefit > that I can get without lock contention. > > Any guidance on how to do so would be appreciated :) I have a very old patch which introduces a config variable (JJNOWAL) that skips all WAL, except for the WAL of certain checkpoints (which are needed for initdb and to restart the server after a clean shutdown). I have rebased it up to HEAD. It seems to work, but I haven't tested thoroughly that it still does the correct thing in every corner case. (a lot of changes have been made to xlog code since last time I used this.) Obviously if the server goes down uncleanly while this setting is active, it will not be usable anymore. Cheers, Jeff
Вложения
В списке pgsql-hackers по дате отправления: