On Sat, 7 Oct 2006, Tom Lane wrote:

"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
I've found a bug with 8.2beta1:

Can you put together a self-contained test case for this?  The planner

I'll try, but it will be quite hard.

is evidently generating an incorrect plan from that messy view, but
trying to reverse-engineer the complete scenario from what you've told
us looks painful.  (No, I don't think the log setting is related.)

At least the plan for the problematic query looks like this

cas=# explain UPDATE table_list SET description = 'tag{image 
SRC="/vizier/new2.gif"}3rd release of DENIS (2005Sep)' WHERE  id = 
cas_get_table_id ('cas_data_sega','b_denis_denis5' );
QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.01..17.11 rows=2 width=82)
   ->  Index Scan using table_user_list_pkey on table_user_list  
(cost=0.00..8.02 rows=1 width=10)
         Index Cond: (cas_get_table_id('cas_data_sega'::character varying, 
'b_denis_denis5'::character varying) = id)
   ->  Append  (cost=0.00..9.07 rows=2 width=76)
         ->  Index Scan using table_user_list_pkey on table_user_list  
(cost=0.00..8.02 rows=1 width=76)
               Index Cond: (id = cas_get_table_id('cas_data_sega'::character 
varying, 'b_denis_denis5'::character varying))
         ->  Seq Scan on table_list  (cost=0.00..1.04 rows=1 width=51)
               Filter: (id = cas_get_table_id('cas_data_sega'::character 
varying, 'b_denis_denis5'::character varying))
(8 rows)

As I see from it, it generates two seq. scans for one table (table_user_list)

Will it be enough to provide the testcase for just that 'expain UPDATE' ?


Sergey E. Koposov
Max Planck Institute for Astronomy/Sternberg Astronomical Institute
Tel: +49-6221-528-349
Web: http://lnfm1.sai.msu.ru/~math

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to