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
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
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
[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
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > g9genarc@eddie:~$ psql -h /var/pgsql --help
> > psql was compiled without support for long options.
> > Use --help for help on invocation options.
> >
> > I guess that it was confused by having both options at once, since
> > "psql --help" wo
Eugene Fokin ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
"hard coded" tk.h search
Long Description
When I build postgresql (its tcl/tk tools and libraries) with
different tcl/tk location, it does use this location to create
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
If there is information which I have not provided, but which would be
usefull, or if the bug can not be reproduced, please let me know.
PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc 2.95.3
- --installed as a SuSE 7.2 package
The foll
Nathan Johnson <[EMAIL PROTECTED]> writes:
> PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc 2.95.3
JOIN syntax isn't implemented (at least not fully or correctly...)
in 7.0. Update to 7.1.
regards, tom lane
---(end of broadcast)-
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
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
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:
> 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
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
Patch applied. Thanks.
> Hi,
>
> I'd like to report a bug in the memory management of libecpg
> (PostgreSQL version 7.1.3).
>
> The ECPGLog() call in ./src/interfaces/ecpg/lib/connect.c line 428
> uses variables pointing to free()'ed storage (`realname', `host',
> `port', and `options', see p
Arcady Genkin writes:
> That's fine, but IMO "psql -h /var/pgsql --help" and "psql --help"
> should either both work, or both not work.
I don't think so.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)-
On 4 Oct 2001, Arcady Genkin wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> > > g9genarc@eddie:~$ psql -h /var/pgsql --help
> > > psql was compiled without support for long options.
> > > Use --help for help on invocation options.
> > >
> > > I guess that it was confused by havi
16 matches
Mail list logo
