Skip site navigation (1) Skip section navigation (2)

Re: Bug #474: Index using problem

From: Andreas Wernitznig <andreas(at)insilico(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bug #474: Index using problem
Date: 2001-10-05 22:37:10
Message-ID: 20011006003710.10febe1a.andreas@insilico.com (view raw or flat)
Thread:
Lists: pgsql-bugs
I don't know how the primary key checking and the index scan are related in postgresql (but I am keen to learn more about it). 
>From Sybase ASA (SQL Anywhere) I know, that these two functions (pk checking, index search) are decoupled.
(that means even a primary key without an index is possible. This makes only sense in tables with a few rows).

The pg-planner takes the current number of datasets to calculate a query plan to reach the best performance.
If the number of datasets changes (and the user/db-programmer usually knows if it changes) the planner sometimes make wrong decisions.
Then I have to execute a "vacuum analyze" or reconnect in case of foreign key checking.

I would like to tune postgresql to use an index in any case if it is available.

On Fri, 05 Oct 2001 18:01:08 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andreas Wernitznig <andreas(at)insilico(dot)com> writes:
> > Why don't you skip the automatic index creation for primary keys
> 
> And how then would we enforce uniqueness of the primary key?
> 
> > and let the user decide to create an index, that should be used in any
> > case, regardless what the query planner recommends ?
> 
> What?  AFAIR the planner does not even *know* whether an index is
> associated with a primary key.  It certainly does not give such an
> index any special preference.
> 
> 			regards, tom lane
> 

In response to

pgsql-bugs by date

Next:From: John SummerfieldDate: 2001-10-05 23:56:38
Subject: Re: Long options for psql in 7.1.3
Previous:From: Tom LaneDate: 2001-10-05 22:01:08
Subject: Re: Bug #474: Index using problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group