Message-ID: <4E1CA8E9.6090108@yahoo.com>
Date: Tue, 12 Jul 2011 13:04:57 -0700
From: lars <lhofhansl@yahoo.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11
MIME-Version: 1.0
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
CC: Ivan Voras <ivoras@freebsd.org>, pgsql-performance@postgresql.org
Subject: Re: UPDATEDs slowing SELECTs in a fully cached	 database
References: <4E16479D.3050605@yahoo.com> <4E1A0CBC.6090009@yahoo.com>
	<4E1A31AB.9010201@postnewspapers.com.au>
	<1310359653.80687.YahooMailRC@web121705.mail.ne1.yahoo.com>
	<4E1AEDAB020000250003F1C3@gw.wicourts.gov>
	<4E1B41EA.90104@yahoo.com>
	<4E1B05CC020000250003F1E6@gw.wicourts.gov>
	<CAHyXU0wPhZsQ_pMzfUWW0O=t_+2uwF-CJQNw-nuaxkjbi2zPEQ@mail.gmail.com>
	<4E1B810D.4070404@yahoo.com> <4E1B90AF.1020408@yahoo.com>
	<ivho9v$6dp$1@dough.gmane.org> <4E1C9A05.7060005@yahoo.com>
	<4E1C5563020000250003F252@gw.wicourts.gov>
In-Reply-To: <4E1C5563020000250003F252@gw.wicourts.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 07/12/2011 12:08 PM, Kevin Grittner wrote:
> 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
So a read of a row *will* trigger dead tuple pruning, and that requires 
WAL logging, and this is known/expected?
This is actually the only answer I am looking for. :) I have not seen 
this documented anywhere.

I know that Postgres will generate general plans for prepared statements 
(how could it do otherwise?),
I also know that it sometimes chooses a sequential scan.
This can always be tweaked to touch fewer rows and/or use a different 
plan. That's not my objective, though!

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.

... Just dropped the table to test something so I can't get the plan 
right now. Will send an update as soon as I get
it setup again.

Thanks again.

-- Lars