Re: UPDATEDs slowing SELECTs in a fully cached database

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Ivan Voras" <ivoras(at)freebsd(dot)org>,"lars" <lhofhansl(at)yahoo(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Date: 2011-07-12 19:08:35
Message-ID: 4E1C5563020000250003F252@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

lars <lhofhansl(at)yahoo(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2011-07-12 19:26:29 Re: UPDATEDs slowing SELECTs in a fully cached database
Previous Message lars 2011-07-12 19:01:25 Re: UPDATEDs slowing SELECTs in a fully cached database