From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCHES] scan_recycle_buffers |
Date: | 2007-03-10 09:42:54 |
Message-ID: | 87abyl1lk1.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> COPY command now also uses this hint, to allow test results and
> discussion. Others could also, perhaps needing different values.
Hm. It occurs to me that different commands may want different size buffer
rings.
As I understand it the reason your buffer rings are more than just a single
target buffer are:
1) For sequential scans because it creates a window for synchronized
sequential scans.
2) For dirty buffers because the dirty evicting the dirty buffer will force an
XLogFlush and we want to give a chance for the WAL pointer to advance past
the buffer's LSN. Ie, to allow other transactions to do our fsync for us
since it won't cost them much extra if anything.
Can you log whenever your ring buffer finds a provides a dirty buffer whose
LSN requires syncing the WAL log? That will help you figure out how large a
ring buffer you need to guarantee property 2.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2007-03-10 10:26:25 | Re: scan_recycle_buffers |
Previous Message | Simon Riggs | 2007-03-10 08:48:31 | Re: scan_recycle_buffers |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2007-03-10 10:26:25 | Re: scan_recycle_buffers |
Previous Message | Simon Riggs | 2007-03-10 08:48:31 | Re: scan_recycle_buffers |