Message-ID: <43EE6877.7080002@obviously.com>
Date: Sat, 11 Feb 2006 14:43:03 -0800
From: Bryce Nesbitt <bryce1@obviously.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921
MIME-Version: 1.0
To: pgsql-sql@postgresql.org
CC: Peter Eisentraut <peter_e@gmx.net>
Subject: Re: Very slow updates when using IN syntax subselect
References: <43ECFF0B.80905@obviously.com> <7972.1139672862@sss.pgh.pa.us>
	<43EE3F77.6020108@obviously.com>
	<200602112134.57572.peter_e@gmx.net>
In-Reply-To: <200602112134.57572.peter_e@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Eisentraut wrote:
> Bryce Nesbitt wrote:
>   
>>> It seems pretty clear that you've never vacuumed nor analyzed these
>>> tables ... else the planner would have some clue about their sizes.
>>> Do that and then see what you get.
>>>       
>> They occur in fine time.  That's good, thanks.  But jeeze, can't
>> postgres figure this out for itself?
>>     
>
> I'm sure you wouldn't appreciate it if PostgreSQL did a full table scan 
> before each query to figure out the total size of the involved tables.
>   
Nope.

But let's say the query optimizer thought the table had one row.
The the query starts, and 111,000 rows later...

It seems that a mismatch between the static table size, and the actual
one counted as you go, would be a quick
check.  That could set a flag for later background processing....

                                                       -Bryce