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
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 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
lars hofhansl lhofha...@yahoo.com 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
On 07/11/2011 10:33 AM, Kevin Grittner wrote:
lars hofhansllhofha...@yahoo.com 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
lars lhofha...@yahoo.com 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
lars lhofha...@yahoo.com 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.
On Mon, Jul 11, 2011 at 2:16 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
lars lhofha...@yahoo.com 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
Merlin Moncure mmonc...@gmail.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
lars lhofha...@yahoo.com 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
On Mon, Jul 11, 2011 at 4:55 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Merlin Moncure mmonc...@gmail.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
lars lhofha...@yahoo.com wrote:
Stopping the UPDATEs, waiting for any CHECKPOINTs to finish,
and then running the
On 07/11/2011 02:43 PM, Merlin Moncure wrote:
On Mon, Jul 11, 2011 at 2:16 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
larslhofha...@yahoo.com wrote:
Stopping the UPDATEs, waiting for any CHECKPOINTs to finish,
and then running the SELECTs indeed shows a similar slowdown.
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
kevin.gritt...@wicourts.gov wrote:
larslhofha...@yahoo.com wrote:
Stopping the UPDATEs, waiting for any CHECKPOINTs to finish,
and then running the SELECTs
On 07/11/2011 08:26 AM, Robert Klemme wrote:
On Mon, Jul 11, 2011 at 3:13 PM, k...@rice.eduk...@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
12 matches
Mail list logo
