Re: Potential Large Performance Gain in WAL synching
От | Tom Lane |
---|---|
Тема | Re: Potential Large Performance Gain in WAL synching |
Дата | |
Msg-id | 760.1033790835@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Potential Large Performance Gain in WAL synching ("Curtis Faith" <curtis@galtair.com>) |
Ответы |
Re: Potential Large Performance Gain in WAL synching
Proposed LogWriter Scheme, WAS: Potential Large Performance Gain in WAL synching |
Список | pgsql-hackers |
"Curtis Faith" <curtis@galtair.com> writes: > After some research I still hold that fsync blocks, at least on > FreeBSD. Am I missing something? > Here's the evidence: > [ much snipped ] > vp = (struct vnode *)fp->f_data; > vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); Hm, I take it a "vnode" is what's usually called an inode, ie the unique identification data for a specific disk file? This is kind of ugly in general terms but I'm not sure that it really hurts Postgres. In our present scheme, the only files we ever fsync() are WAL log files, not data files. And in normal operation there is only one WAL writer at a time, and *no* WAL readers. So an exclusive kernel-level lock on a WAL file while we fsync really shouldn't create any problem for us. (Unless this indirectly blocks other operations that I'm missing?) As I commented before, I think we could do with an extra process to issue WAL writes in places where they're not in the critical path for a foreground process. But that seems to be orthogonal from this issue. regards, tom lane
В списке pgsql-hackers по дате отправления: