| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | lars <lhofhansl(at)yahoo(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Ivan Voras <ivoras(at)freebsd(dot)org>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: UPDATEDs slowing SELECTs in a fully cached database |
| Date: | 2011-07-13 01:16:37 |
| Message-ID: | 21639.1310519797@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On 7/12/11, lars <lhofhansl(at)yahoo(dot)com> wrote:
>> The fact that a select (maybe a big analytical query we'll run) touching
>> many rows will update the WAL and wait
>> (apparently) for that IO to complete is making a fully cached database
>> far less useful.
>> I just artificially created this scenario.
> I can't think of any reason that that WAL would have to be flushed
> synchronously.
Maybe he's running low on shared_buffers? We would have to flush WAL
before writing a dirty buffer out, so maybe excessive pressure on
available buffers is part of the issue here.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mario Splivalo | 2011-07-13 02:04:35 | Re: Planner choosing NestedLoop, although it is slower... |
| Previous Message | Mario Splivalo | 2011-07-13 00:53:32 | Re: Planner choosing NestedLoop, although it is slower... |