Gavin Sherry wrote:
> > > On further thought the real problem is that these numbers are only available
> > > when running with "explain" on. As shown recently on one of the lists, the
> > > cost of the repeated gettimeofday calls can be substantial. It's not really
> > > feasible to suggest running
> > On further thought the real problem is that these numbers are only available
> > when running with "explain" on. As shown recently on one of the lists, the
> > cost of the repeated gettimeofday calls can be substantial. It's not really
> > feasible to suggest running all queries with that profi
Greg Stark <[EMAIL PROTECTED]> writes:
> That's a valid point. The ms/cost factor may not be constant over time.
> However I think in the normal case this number will tend towards a fairly
> consistent value across queries and over time. It will be influenced somewhat
> by things like cache content
Greg Stark <[EMAIL PROTECTED]> writes:
> At least for all the possible plans of a given query at a specific
> point in time the intention is that the cost be proportional to the
> execution time.
Why is this relevant?
Given a cost X at a given point in time, the system needs to derive an
"expect
Neil Conway <[EMAIL PROTECTED]> writes:
> I was thinking about this, but I couldn't think of how to get it to
> work properly:
>
> (1) The optimizer's cost metric is somewhat bogus to begin with.
> ISTM that translating a cost of X into an expected runtime of
> Y msecs is d
Greg Stark <[EMAIL PROTECTED]> writes:
> There's a dual to this as well. If the results were very close but
> the actual time taken to run the node doesn't match the cost
> calculated then some optimizer parameter needs to be adjusted.
I was thinking about this, but I couldn't think of how to get
On Wed, Nov 26, 2003 at 11:59:33AM -0500, Neil Conway wrote:
> > In some situations that doesn't really matter, as the same plan
> > would have gotten picked anyway.
>
> The hint is NOT "the chosen plan was non-optimal"; the hint is "the
> query planner did not produce an accurate row count estim
Tom Lane <[EMAIL PROTECTED]> writes:
> I think such a thing would have such a low signal-to-noise ratio as
> to be useless :-(. As you note, there are many places where the
> planner's estimate is routinely off by more than 3x (or any other
> threshold you might pick instead).
I wonder, perhaps w
Neil Conway <[EMAIL PROTECTED]> writes:
> It occurred to me that these kinds of poor planning decisions could easily
> be detected by PostgreSQL itself: after we've finished executing a plan, we
> can trivially compare the # of results produced by each node in the query
> tree with the # of resul
Neil Conway <[EMAIL PROTECTED]> writes:
> It occurred to me that these kinds of poor planning decisions could
> easily be detected by PostgreSQL itself: after we've finished
> executing a plan, we can trivially compare the # of results produced
> by each node in the query tree with the # of results
> "Neil" == Neil Conway <[EMAIL PROTECTED]> writes:
Neil> It occurred to me that these kinds of poor planning
Neil> decisions could easily be detected by PostgreSQL itself:
Neil> after we've finished executing a plan, we can trivially
Neil> compare the # of results produced by
11 matches
Mail list logo
