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  (Bruce Momjian <pgman@candle.pha.pa.us>)
Proposed LogWriter Scheme, WAS: Potential Large Performance Gain in WAL synching  ("Curtis Faith" <curtis@galtair.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Threaded Sorting
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Potential Large Performance Gain in WAL synching