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
Andreas Wernitznig <[EMAIL PROTECTED]> 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 recomm
Why don't you skip the automatic index creation for primary keys and let the user
decide to create an index,
that should be used in any case, regardless what the query planner recommends ?
On Fri, 05 Oct 2001 15:15:06 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Andreas Wernitznig <[EMAIL PROTEC
Andreas Wernitznig <[EMAIL PROTECTED]> writes:
> -> Using one connection the optimizer for pk/fk-checking is not
> updated by a "vacuum analyze".
Oh, I misunderstood you the first time: I thought you were saying that
*other* backends couldn't see the results of the VACUUM.
The reason for this be
1. I created a small database consisting of two connected tables:
create table table1 (
index1int4not null,
textfield varchar(1000) not null,
constraint PK_table1 primary key (index1)
);
create table table2 (
index2int4not null,
index1int4not null,
textfi
[EMAIL PROTECTED] writes:
> explain select * from cim where utod_cim_id=0;
> NOTICE: QUERY PLAN:
> Seq Scan on cim (cost=0.00..6555.41 rows=253633 width=118)
> The query optimizer does not use my index..
How many rows are there where utod_cim_id=0? The planner guesses that
there are
Andreas Wernitznig <[EMAIL PROTECTED]> writes:
> If I don't disconnect from the database but use the first connection
> again, the database still uses the (now) slower "seq scan" for
> "primary/foreign key" checking. In this case the query optimizer
> statistics are not updated for established con
The query optimizer uses the index only if enough data are present in the table.
If only a few data are available a Seq Scan performs better and is therefore used.
Further one of the problems (which is hopfully solved in version 7.2) is that the
query optimizer used for primary keys/foreign keys
JoE Olcsak ([EMAIL PROTECTED]) reports a bug with a severity of 4
The lower the number the more severe it is.
Short Description
Index using problem
Long Description
I have a problem when using indexes under PostgreSQL 7.1.1 ...
The problem is :
I have a field of table ... This is an INT4 ty
