Re: UPDATEDs slowing SELECTs in a fully cached database - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: UPDATEDs slowing SELECTs in a fully cached database
Date
Msg-id 4E1C5563020000250003F252@gw.wicourts.gov
Whole thread Raw
In response to Re: UPDATEDs slowing SELECTs in a fully cached database  (lars <lhofhansl@yahoo.com>)
Responses Re: UPDATEDs slowing SELECTs in a fully cached database  (lars <lhofhansl@yahoo.com>)
Re: UPDATEDs slowing SELECTs in a fully cached database  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-performance
lars <lhofhansl@yahoo.com> wrote:

> select count(*) from test where tenant = $1 and created_date = $2

Ah, that might be a major clue -- prepared statements.

What sort of a plan do you get for that as a prepared statement?
(Note, it is very likely *not* to be the same plan as you get if you
run with literal values!)  It is not at all unlikely that it could
resort to a table scan if you have one tenant which is five or ten
percent of the table, which would likely trigger the pruning as it
passed over the modified pages.

-Kevin

pgsql-performance by date:

Previous
From: lars
Date:
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Next
From: "Kevin Grittner"
Date:
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database