Re: trouble with (lack of) indexing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
Cc: Søren Boll Overgaard <postgres(at)fork(dot)dk>, pgsql-general(at)postgresql(dot)org
Subject: Re: trouble with (lack of) indexing
Date: 2002-05-10 01:04:09
Message-ID: 24852.1020992649@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk> writes:
> On Thu, 9 May 2002, Tom Lane wrote:
>> There is no "row count at which it's decided a seqscan is better".
>> The planner does cost estimates and picks the plan with the lowest
>> estimated cost, so all the behavior is emergent from the cost
>> estimation equations.

> But those cost estimates can be extrapolated and intersect points determined
> can't they?

Well, many of the equations are nonlinear, and they all have multiple
input values, not to mention various tunable parameters. Solving for
the intersect points is theoretically possible but doesn't strike me
as likely to be informative.

> I haven't looked to see what explanation of the statistics and how the
> planner uses them there is in the documentation. It might be a good
> idea if there was some detail about it there, I mean detail such that
> someone can go to the documentation, query the tables and say 'Ah, so
> that's why it chose that plan.'

The nitty-gritty documentation is in the source code. This is an
open-source project, remember; we operate on the assumption that people
who want to know how things work will look at the sources. Most of the
interesting details for this purpose are in
src/backend/optimizer/path/costsize.c with some tidbits in
src/backend/utils/adt/selfuncs.c

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Lockhart 2002-05-10 01:18:37 Re: newbie - syntax question
Previous Message Nigel J. Andrews 2002-05-10 00:48:46 Re: trouble with (lack of) indexing