On Wed, 2007-02-14 at 10:55 -0500, Tom Lane wrote:
> Rajarshi Guha <[EMAIL PROTECTED]> writes:
> > Clearly a big improvement in performance.
>
> Huh? It looks like exactly the same plan as before. Any improvement
> you're seeing must be coming from cache effects.
Well the new run was done nearl
Martijn van Oosterhout writes:
> There are some more comprehensive writeups around, but hopefully this
> gives you an idea.
You can find the official(tm) explanation at
http://www.postgresql.org/docs/8.2/static/executor.html
--- in fact, you might want to read all of chapter 42.
Rajarshi Guha <[EMAIL PROTECTED]> writes:
> Clearly a big improvement in performance.
Huh? It looks like exactly the same plan as before. Any improvement
you're seeing must be coming from cache effects.
> It looks like theres a big mismatch on the expected and observed costs and
> times.
Well
On Wed, Feb 14, 2007 at 08:22:42AM -0500, Rajarshi Guha wrote:
> (One question not directly related to the problem: when looking at the
> output of explain analyze, I know that one is supposed to start at the
> bottom and move up. Does that that the index scan on pubchem_compound is
> being perform
On Tue, 2007-02-13 at 22:04 -0500, Tom Lane wrote:
> "Adam Rich" <[EMAIL PROTECTED]> writes:
> > This line:
> > Index Scan using plp_total_idx on dockscore_plp
> > (cost=0.00..16733229.92 rows=4669988 width=80)
> > (actual time=98.323..322537.605 rows=25197 loops=1)
> > Means the planner did wha
On Tue, 2007-02-13 at 21:44 -0500, Tom Lane wrote:
> Rajarshi Guha <[EMAIL PROTECTED]> writes:
> > However the clause:
> > dock.target = '1YC1' and
> > dock.dockid = dockscore_plp.id
> > reduces the number of rows from 4.6M to 96K.
>
> The planner seems to be estimating about te
"Adam Rich" <[EMAIL PROTECTED]> writes:
> This line:
> Index Scan using plp_total_idx on dockscore_plp
> (cost=0.00..16733229.92 rows=4669988 width=80)
> (actual time=98.323..322537.605 rows=25197 loops=1)
> Means the planner did what it did, because it estimated there would be
> nearly 5 millio
Rajarshi Guha <[EMAIL PROTECTED]> writes:
> However the clause:
> dock.target = '1YC1' and
> dock.dockid = dockscore_plp.id
> reduces the number of rows from 4.6M to 96K.
The planner seems to be estimating about ten times that many. Perhaps
increasing the statistics target for dock.t
This line:
Index Scan using plp_total_idx on dockscore_plp
(cost=0.00..16733229.92 rows=4669988 width=80)
(actual time=98.323..322537.605 rows=25197 loops=1)
Means the planner did what it did, because it estimated there would be
nearly 5 million rows. However, there were only 25,000.
Have t
