Re: [HACKERS] osdl-dbt3 run results - puzzled by the execution

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: Jenny Zhang <jenny(at)osdl(dot)org>, perf-pgsql <pgsql-performance(at)postgresql(dot)org>, Matt Clark <matt(at)ymogen(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] osdl-dbt3 run results - puzzled by the execution
Date: 2003-09-24 14:01:09
Message-ID: 3530.1064412069@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> Cutting down the number of heap page fetches if PF1 * L > P and P <
> effective_cache_size seems like an obvious improvement, but I was not
> able to figure out where to make this change. Maybe it belongs into
> costsize.c near
> run_cost += outer_path_rows *
> (inner_path->total_cost - inner_path->startup_cost) *
> joininfactor;

I've been intending for some time to try to restructure the cost
estimator so that repeated indexscans can be costed more accurately.
Within the context of the heap-fetch-estimating algorithm, I think
the entire execution of a nestloop-with-inner-index-scan could probably
be treated as a single scan. I'm not sure how we adjust the estimates
for the index-access part, though clearly those are too high as well.

This doesn't seem to be a localized change unfortunately. Certainly
costsize.c can't do it alone.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hans-Jürgen Schönig 2003-09-24 14:32:57 Re: ecpg build on AIX 4.2.1
Previous Message Samuel A Horwitz 2003-09-24 13:49:49 Re: ecpg build on AIX 4.2.1

Browse pgsql-performance by date

  From Date Subject
Next Message Tomasz Myrta 2003-09-24 17:03:06 Re: Index problem
Previous Message Jeff 2003-09-24 12:12:17 Re: LIKE query running slow