Re: [SQL] Very slow updates when using IN syntax subselect

2006-02-11 Thread Tom Lane
Bryce Nesbitt [EMAIL PROTECTED] writes: Tom Lane wrote: What does EXPLAIN show for this and for the base query? - Seq Scan on event (cost=0.00..0.00 rows=1 width=408) Filter: (reconciled = false) select count(*) from event; --- 116226 It seems pretty clear

Re: [SQL] Very slow updates when using IN syntax subselect

2006-02-11 Thread Bryce Nesbitt
Tom Lane wrote: Bryce Nesbitt [EMAIL PROTECTED] writes: Tom Lane wrote: What does EXPLAIN show for this and for the base query? - Seq Scan on event (cost=0.00..0.00 rows=1 width=408) Filter: (reconciled = false) select count(*) from

Re: [SQL] Very slow updates when using IN syntax subselect

2006-02-11 Thread Peter Eisentraut
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

Re: [SQL] Very slow updates when using IN syntax subselect

2006-02-11 Thread Bryce Nesbitt
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

Re: [SQL] Very slow updates when using IN syntax subselect

2006-02-11 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: Bryce Nesbitt wrote: 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