| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: XLogInsert scaling, revisited |
| Date: | 2012-09-20 15:37:42 |
| Message-ID: | 18237.1348155462@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> I've been slowly continuing to work that I started last winder to make
> XLogInsert scale better. I have tried quite a few different approaches
> since then, and have settled on the attached. This is similar but not
> exactly the same as what I did in the patches I posted earlier.
This sounds pretty good. I'm a bit bothered by the fact that you've
settled on 7 parallel-insertion slots after testing on an 8-core
machine. I suspect that it's not a coincidence that you're seeing
a sweet spot for #slots ~= #CPUs. If that is what's happening, we're
going to want to be able to configure the #slots at postmaster start.
Not sure how we'd go about it exactly - is there any reasonably portable
way to find out how many CPUs the machine has? Or do we have to use a
GUC for that?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2012-09-20 15:49:01 | Re: Invalid optimization of VOLATILE function in WHERE clause? |
| Previous Message | Heikki Linnakangas | 2012-09-20 15:29:12 | XLogInsert scaling, revisited |