| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>, pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [HACKERS] 8.3beta1 testing on Solaris |
| Date: | 2007-10-26 00:51:07 |
| Message-ID: | 29721.1193359867@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Didn't we already go through this? He and Simon were pushing to bump up
> NUM_CLOG_BUFFERS and you were arguing that the test wasn't representative and
> some other clog.c would have to be reengineered to scale well to larger
> values.
AFAIR we never did get any clear explanation of what the test case is.
I guess it must be write-mostly, else lazy XID assignment would have
helped this by reducing the rate of XID consumption.
It's still true that I'm leery of a large increase in the number of
buffers without reengineering slru.c. That code was written on the
assumption that there were few enough buffers that a linear search
would be fine. I'd hold still for 16, or maybe even 32, but I dunno
how much impact that will have for such a test case.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2007-10-26 01:11:02 | Re: Autovacuum cancellation |
| Previous Message | Henry B. Hotz | 2007-10-26 00:39:37 | Re: 8.3 GSS Issues |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2007-10-26 02:56:56 | Re: [HACKERS] 8.3beta1 testing on Solaris |
| Previous Message | Gregory Stark | 2007-10-25 22:43:52 | Re: [HACKERS] 8.3beta1 testing on Solaris |