On 07/11/2011 08:26 AM, Robert Klemme wrote:
On Mon, Jul 11, 2011 at 3:13 PM, k...@rice.edu wrote:
I do not know if this makes sense in PostgreSQL and that readers
do not block writers and writes do not block readers. Are your
UPDATEs to individual rows, each in a separate transaction, or
do yo
On 07/11/2011 04:02 PM, lars wrote:
On 07/11/2011 02:43 PM, Merlin Moncure wrote:
On Mon, Jul 11, 2011 at 2:16 PM, Kevin Grittner
wrote:
lars wrote:
Stopping the UPDATEs, waiting for any CHECKPOINTs to finish,
and then running the SELECTs indeed shows a similar slowdown.
Interestingly I s
On 07/11/2011 02:43 PM, Merlin Moncure wrote:
On Mon, Jul 11, 2011 at 2:16 PM, Kevin Grittner
wrote:
lars wrote:
Stopping the UPDATEs, waiting for any CHECKPOINTs to finish,
and then running the SELECTs indeed shows a similar slowdown.
Interestingly I see very heavy WAL traffic while execu
On Mon, Jul 11, 2011 at 4:55 PM, Kevin Grittner
wrote:
> Merlin Moncure wrote:
>> Kevin Grittner wrote:
>>> lars wrote:
>>>
Stopping the UPDATEs, waiting for any CHECKPOINTs to finish,
and then running the SELECTs indeed shows a similar slowdown.
Interestingly I see very hea
Merlin Moncure wrote:
> Kevin Grittner wrote:
>> lars wrote:
>>
>>> Stopping the UPDATEs, waiting for any CHECKPOINTs to finish,
>>> and then running the SELECTs indeed shows a similar slowdown.
>>>
>>> Interestingly I see very heavy WAL traffic while executing the
>>> SELECTs. (So I was confuse
On Mon, Jul 11, 2011 at 2:16 PM, Kevin Grittner
wrote:
> lars wrote:
>
>> Stopping the UPDATEs, waiting for any CHECKPOINTs to finish,
>> and then running the SELECTs indeed shows a similar slowdown.
>>
>> Interestingly I see very heavy WAL traffic while executing the
>> SELECTs. (So I was confus
lars wrote:
> We are maintaining a large multi tenant database where *all*
> tables have a tenant-id and all indexes and PKs lead with the
> tenant-id. Statistics and counts for the all other columns are
> only really meaningful within the context of the tenant they
> belong to.
>
> There appea
lars wrote:
> Stopping the UPDATEs, waiting for any CHECKPOINTs to finish,
> and then running the SELECTs indeed shows a similar slowdown.
>
> Interestingly I see very heavy WAL traffic while executing the
> SELECTs. (So I was confused as to what caused the WAL traffic).
Hint bit changes aren
On 07/11/2011 10:33 AM, Kevin Grittner wrote:
lars hofhansl wrote:
Yep, I am not seeing the SELECTs slow down (measurably) during
checkpoints (i.e. when dirty pages are flushed to disk), but only
during writing of the WAL files.
How about if you do a whole slew of the UPDATEs and then stop t
lars hofhansl wrote:
> Yep, I am not seeing the SELECTs slow down (measurably) during
> checkpoints (i.e. when dirty pages are flushed to disk), but only
> during writing of the WAL files.
How about if you do a whole slew of the UPDATEs and then stop those
and run a bunch of SELECTs? (I don'
On Mon, Jul 11, 2011 at 05:26:49PM +0200, Robert Klemme wrote:
> On Mon, Jul 11, 2011 at 3:13 PM, k...@rice.edu wrote:
> > I do not know if this makes sense in PostgreSQL and that readers
> > do not block writers and writes do not block readers. Are your
> > UPDATEs to individual rows, each in a s
On Mon, Jul 11, 2011 at 3:13 PM, k...@rice.edu wrote:
> I do not know if this makes sense in PostgreSQL and that readers
> do not block writers and writes do not block readers. Are your
> UPDATEs to individual rows, each in a separate transaction, or
> do you UPDATE multiple rows in the same trans
Hi Lars,
I do not know if this makes sense in PostgreSQL and that readers
do not block writers and writes do not block readers. Are your
UPDATEs to individual rows, each in a separate transaction, or
do you UPDATE multiple rows in the same transaction? If you
perform multiple updates in a single t
13 matches
Mail list logo
