Maxim Boguk writes:
> [ planner changes behavior when a VALUES RTE reaches 200 elements ]
The immediate cause of that is that, lacking any real statistics for the
VALUES RTE, eqjoinsel_semi() will fall back to a rather dubious default
estimate if it believes it's looking at a default estimate for
Hi,
I found very weird behaviour on planner side with estimation error of
700.000.000.
Situation (with explain analyze):
EXPLAIN ANALYZE
select * from person2obj
WHERE
p2o_id IN (SELECT p2o_id::bigint FROM (SELECT * FROM (SELECT column1 AS
p2o_id FROM (
VALUES ('2056892'), up to
Charlie Clark <[EMAIL PROTECTED]> writes:
> Am 09.03.2007 um 16:15 schrieb Tom Lane:
>> There's your problem right there. The string comparison routines are
>> built on strcoll(), which is going to expect UTF8-encoded data because
>> of the LC_COLLATE setting. If there are any high-bit-set LATIN1
Am 09.03.2007 um 16:15 schrieb Tom Lane:
psytec=# show lc_collate;
lc_collate
-
de_DE.UTF-8
(1 row)
psytec=# show server_encoding;
server_encoding
-
LATIN1
(1 row)
There's your problem right there. The string comparison routines are
built on strcoll(), which is
Charlie Clark <[EMAIL PROTECTED]> writes:
> psytec=# show lc_collate;
> lc_collate
> -
> de_DE.UTF-8
> (1 row)
> psytec=# show server_encoding;
> server_encoding
> -
> LATIN1
> (1 row)
There's your problem right there. The string comparison routines are
built on strco
Am 09.03.2007 um 05:30 schrieb Tom Lane:
Charlie Clark <[EMAIL PROTECTED]> writes:
I'm getting unexpected results on a query which involves joining two
tables on two common variables (firstname and lastname).
That looks like it should work. Given that you describe the
columns as
"names"
Charlie Clark <[EMAIL PROTECTED]> writes:
> I'm getting unexpected results on a query which involves joining two
> tables on two common variables (firstname and lastname).
That looks like it should work. Given that you describe the columns as
"names" I'm supposing they are of textual datatypes.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/08/07 16:09, Charlie Clark wrote:
> Hi,
>
> I'm getting unexpected results on a query which involves joining two
> tables on two common variables (firstname and lastname).
>
> This is the basic query:
>
> SELECT table1.lastname, table1.firstna
What happens if you do an outer join instead of an inner join?
Charlie Clark wrote:
Hi,
I'm getting unexpected results on a query which involves joining two
tables on two common variables (firstname and lastname).
This is the basic query:
SELECT table1.lastname, table1.firstname
FROM table
Hi,
I'm getting unexpected results on a query which involves joining two
tables on two common variables (firstname and lastname).
This is the basic query:
SELECT table1.lastname, table1.firstname
FROM table1
INNER JOIN table2 ON
(table2.name = table1.name
AND
table2.vorname = table1.vorname
sorry, i forgot some version number :)
[mat@biniac ~]$ psql --version
psql (PostgreSQL) 7.1.2
contains readline, history support
Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
Portions Copyright (c) 1996 Regents of the University of California
Read the file COPYRIGHT or
hi,
i'm notice a weird behaviour while running a query on the same table,
the query take a long time to be executed when this table is empty ,
and when this table isn't empty, it take about 1/2 second
the two tables are freshly vacuumed ...
here the same tables, one is empty, not the other
12 matches
Mail list logo
