| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)sun(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [HACKERS] 8.3beta1 testing on Solaris |
| Date: | 2007-10-26 02:56:56 |
| Message-ID: | 200710251956.56744.josh@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
Tom,
> 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.
Actually, 32 made a significant difference as I recall ... do you still have
the figures for that, Jignesh?
The test case is a workload called "iGen" which is a "fixed" TPCC-like
workload. I've been trying to talk Sun into open-sourcing it, but no dice so
far. It is heavy on writes, and (like TPCC) consists mostly of one-line
transactions.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-10-26 03:26:08 | Re: [HACKERS] 8.3beta1 testing on Solaris |
| Previous Message | Alvaro Herrera | 2007-10-26 01:11:02 | Re: Autovacuum cancellation |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-10-26 03:26:08 | Re: [HACKERS] 8.3beta1 testing on Solaris |
| Previous Message | Tom Lane | 2007-10-26 00:51:07 | Re: [HACKERS] 8.3beta1 testing on Solaris |