From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brice Ruth <brice(at)webprojkt(dot)com> |
Cc: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-general(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: [SQL] Query never returns ... |
Date: | 2001-02-08 18:50:57 |
Message-ID: | 12434.981658257@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-sql |
Brice Ruth <brice(at)webprojkt(dot)com> writes:
> As for vacuum analyze - prior to running into these problems, I deleted
> all data from the database (using delete from <tblname>) and then ran
> vacuumdb -a, after which I loaded the data into the tables using 'copy
> ... from' - there have been no updates to the database since then -
> merely selects.
That was the wrong order to do things in :-(. The VACUUM ANALYZE posted
statistics showing all your tables as empty, and the planner is now
faithfully choosing plans that are good for tiny tables --- ie, minimal
startup cost and don't worry about per-tuple cost.
There has been some talk of having stats automatically updated by COPY,
but right now it doesn't happen. So the correct procedure is to do a
VACUUM ANALYZE on a table *after* you do any sizable data additions.
BTW, people have occasionally stated on the list that you need to redo
VACUUM ANALYZE after adding/dropping indexes, but that's not true, at
least not in the present state of the world. VACUUM ANALYZE only posts
stats about the data in the table(s). The planner always looks at the
current set of indices for a table, together with the last-posted data
statistics, to choose a plan.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-02-08 19:00:00 | Re: Fw: [PHP] Fooling the query optimizer |
Previous Message | Emmanuel Pierre | 2001-02-08 18:40:52 | serious performance problem |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-02-08 19:37:16 | Re: PL/pgsql EXECUTE 'SELECT INTO ...' |
Previous Message | Alex Pilosov | 2001-02-08 18:27:27 | Re: Re: [SQL] Query never returns ... |