Re: Problema Order By en PosgreSQL 8.1

Hola a todos.

Tengo un problema de lo mas increible, resulta que tengo un query simple:

select tabla1.A , tabla2.B , tabla3.C
from tabla1, tabla2, tabla3
where etc, etc
order by tabla3.C

e increiblemente el order by NO se hace para nada.

Estuve tratando de entender por que no me hacia caso el posgreSQL ,
primero hice el cambio a order by descendente y funcionaba, luego fui
al pgadmin y quize ver los datos de la tabla3 , me salio la ventanasa
de :

"Running VACUUM recommended"

asi que hice caso a ver lo que pasaba, e increiblemente ahora si corre
el select cuestionado con la ordenacion ascendente.

Trate de reproducir el error para ver si el problema es de la BD y no
una cuestion meramente de mala suerte, y me volvio a salir el mismo
error. Entonces ante esto, mi hipotesis es que eal posgreSQL 8.1
requiere estarle haciendo vacuum a cada rato sino hasta las cosas mas
simples como un ordenamiento no las hará correctamente ??? y por que
el posgres antiguo que tenia ( 7.X ) no me da problemas siendo mas
antiguo ?

Alguna idea de que puede estar pasando.

Gracias de antemano.

Paolo.

Paolo Lopez escribió:
> Hola a todos.
>
> Tengo un problema de lo mas increible, resulta que tengo un query simple:
>
> select tabla1.A , tabla2.B , tabla3.C
> from tabla1, tabla2, tabla3
> where etc, etc
> order by tabla3.C
>
> e increiblemente el order by NO se hace para nada.

Veamos un caso de prueba? Si es asi como tu dices es tremendamente
grave, pero tengo mis dudas.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Bueno, lo del caso de prueba estoy viendo en lo posible enviar un
ejemplo concreto. Pero en relacion al problema , mando la pantalla que
me sale :

pgadmin III Guru Hint - running VACUUM recommended
The estimated rowcount on the table "" deviates significantly from
the actual rowcount.
You should run VACUUM ANALYZE on this table.

Y segun lo que he leido de esto en el HELP, ademas de otra informacion
de la internet, es que el dichoso ORDER BY no se va a efectuar
correctamente debido a que forzosamente debe de hacerse un vacuum.

Alguien se ha topado con este problema ??

No entiendo como es posible que una de las ultimas versiones, la 8.1
tenga que pedir VACUUM para ordenamiento de solo 40 registros ?? es
increible.

Paolo.

On 4/5/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Paolo Lopez escribió:
> > Hola a todos.
> >
> > Tengo un problema de lo mas increible, resulta que tengo un query simple:
> >
> > select tabla1.A , tabla2.B , tabla3.C
> > from tabla1, tabla2, tabla3
> > where etc, etc
> > order by tabla3.C
> >
> > e increiblemente el order by NO se hace para nada.
>
> Veamos un caso de prueba? Si es asi como tu dices es tremendamente
> grave, pero tengo mis dudas.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>

Paolo Lopez escribió:

> pgadmin III Guru Hint - running VACUUM recommended
> The estimated rowcount on the table "" deviates significantly from
> the actual rowcount.
> You should run VACUUM ANALYZE on this table.
>
>
> Y segun lo que he leido de esto en el HELP, ademas de otra informacion
> de la internet, es que el dichoso ORDER BY no se va a efectuar
> correctamente debido a que forzosamente debe de hacerse un vacuum.

Lo que dices no tiene sentido y creo que has leido mal el help, o estas
leyendo informacion de la internet que es incorrecta. El hint
ciertamente no dice eso.

> No entiendo como es posible que una de las ultimas versiones, la 8.1
> tenga que pedir VACUUM para ordenamiento de solo 40 registros ?? es
> increible.

Esto no es asi.

Creo que estas confundiendo los sintomas. Estoy dispuesto a creer que
un ORDER BY entregue un orden que no sea el que esperas, dadas ciertas
condiciones; por eso te pedi el caso de prueba, para que veamos cuales
son las posibles explicaciones (y como corregirlo). Pero eso no tiene
nada que ver con el VACUUM.

BTW el caso de prueba puede ser muy sencillo: muestra simplemente la
definicion de las tablas, el SELECT y la salida de este.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

> Y segun lo que he leido de esto en el HELP, ademas de otra informacion
> de la internet, es que el dichoso ORDER BY no se va a efectuar
> correctamente debido a que forzosamente debe de hacerse un vacuum.
>

y que parte del HELP te dio a entender eso? si efectivamente da a
entender eso, habria que proponer una manera distinta de explicar las
cosas

--
Atentamente,
Jaime Casanova

"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
Randal L. Schwartz

A ver, como dice Alvaro mejor es tener un caso de prueba concreto para
asi entender el problema que estoy experimentando.

Pasos para reproduccion del error:

1) Tener instalado postgreSQL 8.1 en windows xp profesional.

2) Crear una base de datos vacía con encoding UTF-8.

3) Crear la siguente tabla , con sus PK , y 40 datos de prueba:

CREATE TABLE tablita (
campoA integer NOT NULL,
campoB integer NOT NULL,
campoC integer NOT NULL,
campoD integer NOT NULL,
campoE integer NOT NULL,
campoF integer NOT NULL,
iddia integer NOT NULL,
numhora integer NOT NULL,
horainicio time without time zone,
horafin time without time zone
);

ALTER TABLE ONLY tablita
ADD CONSTRAINT tablita_pkey PRIMARY KEY (campoA, campoB, campoC,
campoD, campoE, campoF, iddia, numhora);

INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 1, 1, '08:00:00', '08:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 1, 2, '08:45:00', '09:30:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 1, 3, '09:30:00', '10:15:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 1, 4, '10:15:00', '11:00:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 1, 5, '11:00:00', '11:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 1, 6, '12:15:00', '13:00:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 1, 7, '13:00:00', '13:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 1, 8, '13:45:00', '14:30:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 2, 1, '08:00:00', '08:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 2, 2, '08:45:00', '09:30:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 2, 3, '09:30:00', '10:15:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 2, 4, '10:15:00', '11:00:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 2, 5, '11:00:00', '11:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 2, 6, '12:15:00', '13:00:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 2, 7, '13:00:00', '13:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 2, 8, '13:45:00', '14:30:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 3, 1, '08:00:00', '08:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 3, 2, '08:45:00', '09:30:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 3, 3, '09:30:00', '10:15:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 3, 4, '10:15:00', '11:00:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 3, 5, '11:00:00', '11:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 3, 6, '12:15:00', '13:00:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 3, 7, '13:00:00', '13:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 3, 8, '13:45:00', '14:30:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 4, 1, '08:00:00', '08:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 4, 2, '08:45:00', '09:30:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 4, 3, '09:30:00', '10:15:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 4, 4, '10:15:00', '11:00:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 4, 5, '11:00:00', '11:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 4, 6, '12:15:00', '13:00:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 4, 7, '13:00:00', '13:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 4, 8, '13:45:00', '14:30:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 5, 1, '08:00:00', '08:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 5, 2, '08:45:00', '09:30:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 5, 3, '09:30:00', '10:15:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 5, 4, '10:15:00', '11:00:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 5, 5, '11:00:00', '11:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 5, 6, '12:15:00', '13:00:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 1, 5, 7, '13:00:00', '13:45:00');
INSERT INTO tablita (campoA, campoB, campoC, campoD, campoE, campoF,
iddia, numhora, horainicio, horafin) VALUES (1, 1, 1, 1,

1, 2, 5, 8, '13:45:00', '14:30:00');

4) Hacer el siguiente query con el ORDER BY que se quiere :

select *
from tablita
WHERE tablita.campoA = 1 AND
tablita.campoB = 1 AND
tablita.campoC = 1 AND
tablita.campoD = 1 AND
tablita.campoE = 1
ORDER BY tablita.idDia , tablita.numHora

Conclusiones :

C1) El ejemplo dado NO ordena en la version 8.1 . Pero si uno va al
pgadmin, y hace click en la tabla "tablita" inmediatamente sale la
ventana de "Guru Hint" con lo siguiente :

Running VACUUM recommended
The estimated rowcount on the table "tablita" deviates
significantly from the actual
rowcount. You should run VACUUM ANALYZE on this table.

posibles opciones ante esto:

C1.1) Si NO se hace caso al "Guru Hint" el ordenamiento
ascendente nunca se
efectuará.

C1.2) Si SI hace caso al "Guru Hint" (vacuum analyze) el
ordenamiento ascendente
se efectuará como se ha previsto.

C2) El ejemplo dado SI ordena en la version 7.4.1 corriendo en cygwin
, y en windows xp professional. No se experimentan problemas.

Y listo señores, el ejemplo pedido se los acabo de proporcionar.
Adicionalmente he puesto todo el ejemplo en un archivo Ejemplo2.zip
que tambien lo estoy enviando.

Espero esta vez haber sido detallado en cuanto a este problema.

Gracias de antemano por la ayuda que me puedan brindar.

Paolo.

On 4/6/06, Jaime Casanova <systemguards(at)gmail(dot)com> wrote:
> > Y segun lo que he leido de esto en el HELP, ademas de otra informacion
> > de la internet, es que el dichoso ORDER BY no se va a efectuar
> > correctamente debido a que forzosamente debe de hacerse un vacuum.
> >
>
> y que parte del HELP te dio a entender eso? si efectivamente da a
> entender eso, habria que proponer una manera distinta de explicar las
> cosas
>
> --
> Atentamente,
> Jaime Casanova
>
> "What they (MySQL) lose in usability, they gain back in benchmarks, and that's
> all that matters: getting the wrong answer really fast."
> Randal L. Schwartz
>

Paolo Lopez wrote:

>A ver, como dice Alvaro mejor es tener un caso de prueba concreto para
>asi entender el problema que estoy experimentando.
>
>Pasos para reproduccion del error:
>
>1) Tener instalado postgreSQL 8.1 en windows xp profesional.
>
>2) Crear una base de datos vacía con encoding UTF-8.
>
>3) Crear la siguente tabla , con sus PK , y 40 datos de prueba:
>
>
>CREATE TABLE tablita (
> campoA integer NOT NULL,
> campoB integer NOT NULL,
> campoC integer NOT NULL,
> campoD integer NOT NULL,
> campoE integer NOT NULL,
> campoF integer NOT NULL,
> iddia integer NOT NULL,
> numhora integer NOT NULL,
> horainicio time without time zone,
> horafin time without time zone
>);
>
>
>
> C1.1) Si NO se hace caso al "Guru Hint" el ordenamiento
>ascendente nunca se
> efectuará.
>
>
>

Que esperar obtener en el query ? porque dices que no se ordena, a mi me
funciona con tu ejemplo.

prueba_ordenar=# select tablita.idDia , tablita.numHora
prueba_ordenar-# from tablita
prueba_ordenar-# WHERE tablita.campoA = 1 AND
prueba_ordenar-# tablita.campoB =
1 AND
prueba_ordenar-# tablita.campoC =
1 AND
prueba_ordenar-# tablita.campoD =
1 AND
prueba_ordenar-# tablita.campoE = 1
prueba_ordenar-# ORDER BY tablita.idDia , tablita.numHora;
iddia | numhora
-------+---------
1 | 1
1 | 2
1 | 3
1 | 4
1 | 5
1 | 6
1 | 7
1 | 8
2 | 1
2 | 2
2 | 3
2 | 4
2 | 5
2 | 6
2 | 7
2 | 8
3 | 1
3 | 2
3 | 3
3 | 4
3 | 5
3 | 6
3 | 7
3 | 8
4 | 1
4 | 2
4 | 3
4 | 4
4 | 5
4 | 6
4 | 7
4 | 8
5 | 1
5 | 2
5 | 3
5 | 4
5 | 5
5 | 6
5 | 7
5 | 8
(40 rows)

Verificado en gentoo y freebsd
atte

Paolo Lopez escribió:

> C1) El ejemplo dado NO ordena en la version 8.1 .

Lo probe aca y funciona perfectamente. Puede ser un problema de UTF8 en
Windows, pero hasta donde veo los campos involucrados son numeros, no
cadenas de caracteres, por lo que eso no deberia afectar para nada.

Alguien tendria que probarlo en Windows. Yo aca no tengo como.

> C1.1) Si NO se hace caso al "Guru Hint" el ordenamiento
> ascendente nunca se
> efectuará.
>
> C1.2) Si SI hace caso al "Guru Hint" (vacuum analyze) el
> ordenamiento ascendente
> se efectuará como se ha previsto.

Como te digo, el vacuum analyze no puede tener ningun efecto.

Que tal si publicas el EXPLAIN ANALYZE de la consulta, antes y despues
del vacuum analyze?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Miguel: gracias por probar el ejemplo. Fue en 8.1 , no ?

Mando los reultados que a mi me estan saliendo:

Paul2=# select tablita.idDia , tablita.numHora
Paul2-# from tablita
Paul2-# WHERE tablita.campoA = 1 AND
Paul2-# tablita.campoB =1 AND
Paul2-# tablita.campoC =1 AND
Paul2-# tablita.campoD =1 AND
Paul2-# tablita.campoE = 1
Paul2-# ORDER BY tablita.idDia , tablita.numHora;
iddia | numhora
-------+---------
1 | 1
1 | 2
1 | 3
1 | 4
1 | 5
1 | 6
1 | 7
1 | 8
3 | 1
3 | 2
3 | 3
3 | 4
3 | 5
3 | 6
3 | 7
3 | 8
5 | 1
5 | 3
5 | 5
5 | 7
2 | 1
2 | 2
2 | 3
2 | 4
2 | 5
2 | 6
2 | 7
2 | 8
4 | 1
4 | 2
4 | 3
4 | 4
4 | 5
4 | 6
4 | 7
4 | 8
5 | 2
5 | 4
5 | 6
5 | 8
(40 rows)

Alvaro:

Acabo de probar el ejemplo tanto en UTF-8 y Latin1, y el resultado es
el mismo, no hay ordenamiento. Te mando lo que me pediste:

EXPLAIN ANALYZE , antes del vacuum analyze:

Index Scan using tablita_pkey on tablita (cost=0.00..5.83 rows=1
width=8) (actual time=0.044..0.179 rows=40 loops=1)
Index Cond: ((campoa = 1) AND (campob = 1) AND (campoc = 1) AND
(campod = 1) AND (campoe = 1))
Total runtime: 0.303 ms

el vacuum analyze de "tablita" sale :

INFO: vacuuming "public.tablita"
INFO: index "tablita_pkey" now contains 40 row versions in 2 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "tablita": found 0 removable, 40 nonremovable row versions in 1 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: analyzing "public.tablita"
INFO: "tablita": scanned 1 of 1 pages, containing 40 live rows and 0
dead rows; 40 rows in sample, 40 estimated total rows

Total query runtime: 260 ms.

EXPLAIN ANALYZE , despues del vacuum analyze:

Sort (cost=2.96..3.06 rows=40 width=8) (actual time=0.326..0.363
rows=40 loops=1)
Sort Key: iddia, numhora
-> Seq Scan on tablita (cost=0.00..1.90 rows=40 width=8) (actual
time=0.026..0.179 rows=40 loops=1)
Filter: ((campoa = 1) AND (campob = 1) AND (campoc = 1) AND
(campod = 1) AND (campoe = 1))
Total runtime: 0.485 ms

Paolo.

On 4/7/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Paolo Lopez escribió:
>
> > C1) El ejemplo dado NO ordena en la version 8.1 .
>
> Lo probe aca y funciona perfectamente. Puede ser un problema de UTF8 en
> Windows, pero hasta donde veo los campos involucrados son numeros, no
> cadenas de caracteres, por lo que eso no deberia afectar para nada.
>
> Alguien tendria que probarlo en Windows. Yo aca no tengo como.
>
> > C1.1) Si NO se hace caso al "Guru Hint" el ordenamiento
> > ascendente nunca se
> > efectuará.
> >
> > C1.2) Si SI hace caso al "Guru Hint" (vacuum analyze) el
> > ordenamiento ascendente
> > se efectuará como se ha previsto.
>
> Como te digo, el vacuum analyze no puede tener ningun efecto.
>
> Que tal si publicas el EXPLAIN ANALYZE de la consulta, antes y despues
> del vacuum analyze?
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>

Otro dato mas sobre este problema: el error me sale tanto en mi
maquina donde desarrollo como en la maquina del cliente en donde he
instalado el producto. Ambos postgre SQL 8.1 en windows XP
professional.

Por lo tanto he descartado el problema debido a fallas o mala suerte.

Paolo.

Paolo Lopez escribió:

> Mando los reultados que a mi me estan saliendo:

Ok, claramente esta malo.

> EXPLAIN ANALYZE , antes del vacuum analyze:
>
> Index Scan using tablita_pkey on tablita (cost=0.00..5.83 rows=1
> width=8) (actual time=0.044..0.179 rows=40 loops=1)
> Index Cond: ((campoa = 1) AND (campob = 1) AND (campoc = 1) AND
> (campod = 1) AND (campoe = 1))
> Total runtime: 0.303 ms

Observa que aca esta siguiendo el indice de la llave primaria.
Obviamente deberia entregar el resultado en el mismo orden que tu lo
pediste.

> Sort (cost=2.96..3.06 rows=40 width=8) (actual time=0.326..0.363
> rows=40 loops=1)
> Sort Key: iddia, numhora
> -> Seq Scan on tablita (cost=0.00..1.90 rows=40 width=8) (actual
> time=0.026..0.179 rows=40 loops=1)
> Filter: ((campoa = 1) AND (campob = 1) AND (campoc = 1) AND
> (campod = 1) AND (campoe = 1))

Aca no usa el indice sino que la tabla directamente, y despues ordena el
resultado.

Creo que a lo que esto apunta es que el indice esta corrupto por uno u
otro motivo.

Por favor prueba lo siguiente: crea la tabla y agrega los resultados,
tal como lo hiciste antes. Ejecuta VACUUM ANALYZE tablita, y despues

SET enable_seqscan TO off;
y prueba nuevamente la consulta. Envia el EXPLAIN ANALYZE, y verifica
si el orden es correcto o no.

Luego: borra el indice. ALTER TABLE tablita DROP PRIMARY KEY. Luego
crealo de nuevo: ALTER TABLE tablita ADD PRIMARY KEY ( ... )
Luego
SET enable_seqscan TO off;
y la consulta otra vez; pega el EXPLAIN ANALYZE e indica si el resultado
es correcto o no.

Me gustaria saber si alguien mas puede reproducir este problema en
Windows.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Hola,

--- Paolo Lopez <murphyperu(at)gmail(dot)com> wrote:

> Miguel: gracias por probar el ejemplo. Fue en 8.1 ,
> no ?
>
>
> Mando los reultados que a mi me estan saliendo:
>
>
> Paul2=# select tablita.idDia , tablita.numHora
> Paul2-# from tablita
> Paul2-# WHERE tablita.campoA = 1
> AND
> Paul2-# tablita.campoB =1 AND
> Paul2-# tablita.campoC =1 AND
> Paul2-# tablita.campoD =1 AND
> Paul2-# tablita.campoE = 1
> Paul2-# ORDER BY tablita.idDia , tablita.numHora;
> iddia | numhora
> -------+---------
> 1 | 1
> [...]

Probé en PostgreSQL 8.1 sobre windows xp (sp2) y no
existe el problema que mencionas, los datos salen
correctamente ordenados..., por los datos que muestras
al parecer no estás usando ORDER BY, digo esto,
porque cuando quité esa parte de la consulta recién
puedo reproducir tu *problema*.

Saludos

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Alvaro:

>
> Por favor prueba lo siguiente: crea la tabla y agrega los resultados,
> tal como lo hiciste antes. Ejecuta VACUUM ANALYZE tablita, y despues
>
> SET enable_seqscan TO off;
> y prueba nuevamente la consulta.

Me salé:

Paul2=# select tablita.idDia , tablita.numHora
Paul2-# from tablita
Paul2-# WHERE tablita.campoA = 1 AND
Paul2-# tablita.campoB =1 AND
Paul2-# tablita.campoC =1 AND
Paul2-# tablita.campoD =1 AND
Paul2-# tablita.campoE = 1
Paul2-# ORDER BY tablita.idDia , tablita.numHora;
iddia | numhora
-------+---------
1 | 1
1 | 2
1 | 3
1 | 4
1 | 5
1 | 6
1 | 7
1 | 8
2 | 1
2 | 2
2 | 3
2 | 4
2 | 5
2 | 6
2 | 7
2 | 8
3 | 1
3 | 2
3 | 3
3 | 4
3 | 5
3 | 6
3 | 7
3 | 8
4 | 1
4 | 2
4 | 3
4 | 4
4 | 5
4 | 6
4 | 7
4 | 8
5 | 1
5 | 2
5 | 3
5 | 4
5 | 5
5 | 6
5 | 7
5 | 8
(40 rows)

> Envia el EXPLAIN ANALYZE, y verifica

El EXPLAIN salé :

Sort (cost=2.96..3.06 rows=40 width=8) (actual time=0.338..0.375
rows=40 loops=1)
Sort Key: iddia, numhora
-> Seq Scan on tablita (cost=0.00..1.90 rows=40 width=8) (actual
time=0.028..0.188 rows=40 loops=1)
Filter: ((campoa = 1) AND (campob = 1) AND (campoc = 1) AND
(campod = 1) AND (campoe = 1))
Total runtime: 0.501 ms

> si el orden es correcto o no.

el orden es correcto :)

>
> Luego: borra el indice. ALTER TABLE tablita DROP PRIMARY KEY.

borrado constraint

tablita_pkey PRIMARY KEY (campoA, campoB, campoC, campoD, campoE,
campoF, iddia, numhora);

> Luego
> crealo de nuevo: ALTER TABLE tablita ADD PRIMARY KEY ( ... )

creando:

ALTER TABLE ONLY tablita
ADD CONSTRAINT tablita_pkey PRIMARY KEY (campoA, campoB, campoC,
campoD, campoE, campoF, iddia, numhora);

> Luego
> SET enable_seqscan TO off;
> y la consulta otra vez; pega el EXPLAIN ANALYZE

me salé :

Sort (cost=2.96..3.06 rows=40 width=8) (actual time=0.330..0.368
rows=40 loops=1)
Sort Key: iddia, numhora
-> Seq Scan on tablita (cost=0.00..1.90 rows=40 width=8) (actual
time=0.026..0.184 rows=40 loops=1)
Filter: ((campoa = 1) AND (campob = 1) AND (campoc = 1) AND
(campod = 1) AND (campoe = 1))
Total runtime: 0.491 ms

> e indica si el resultado
> es correcto o no.
>

me sale correcto :)

Paul2=# select tablita.idDia , tablita.numHora
Paul2-# from tablita
Paul2-# WHERE tablita.campoA = 1 AND
Paul2-# tablita.campoB =1 AND
Paul2-# tablita.campoC =1 AND
Paul2-# tablita.campoD =1 AND
Paul2-# tablita.campoE = 1
Paul2-# ORDER BY tablita.idDia , tablita.numHora;
iddia | numhora
-------+---------
1 | 1
1 | 2
1 | 3
1 | 4
1 | 5
1 | 6
1 | 7
1 | 8
2 | 1
2 | 2
2 | 3
2 | 4
2 | 5
2 | 6
2 | 7
2 | 8
3 | 1
3 | 2
3 | 3
3 | 4
3 | 5
3 | 6
3 | 7
3 | 8
4 | 1
4 | 2
4 | 3
4 | 4
4 | 5
4 | 6
4 | 7
4 | 8
5 | 1
5 | 2
5 | 3
5 | 4
5 | 5
5 | 6
5 | 7
5 | 8
(40 rows)

>
> Me gustaria saber si alguien mas puede reproducir este problema en
> Windows.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

Paolo.

Saludos listeros

Tengo problemas para hacer una restaura, sencillamente y resumiendo, tengo
mi BD realizo una salva con el pgAdmin III y cuando trato de hacer una
restaura en otro lugar emite el siguiente error.

pg_restore: ERROR: duplicate key violates unique constraint
"tb_arch_acceso_utilizacion_pkey"
CONTEXT: COPY tb_arch_acceso_utilizacion, line 1: "1 "
pg_restore: [archiver (db)] error returned by PQendcopy
pg_restore: *** aborted because of error

El proceso retornó el código de salida 1.

Entiendo el error pero, si supuestamente está trabajando bien, por que
cuando trato de restaurarla aborta...

Gracias de antemano.

Gracias Alex por probar.

Me sigue pareciendo raro este problema y encima en 2 maquinas y sobre
el mismo query, para esta version 8.1.0 ( no es 8.1.1, ni 8.1.2, ni
8.1.3 )

Paolo.

On 4/7/06, Alex Concha <xkn0wn(at)yahoo(dot)com> wrote:
> Hola,
>
> --- Paolo Lopez <murphyperu(at)gmail(dot)com> wrote:
>
> > Miguel: gracias por probar el ejemplo. Fue en 8.1 ,
> > no ?
> >
> >
> > Mando los reultados que a mi me estan saliendo:
> >
> >
> > Paul2=# select tablita.idDia , tablita.numHora
> > Paul2-# from tablita
> > Paul2-# WHERE tablita.campoA = 1
> > AND
> > Paul2-# tablita.campoB =1 AND
> > Paul2-# tablita.campoC =1 AND
> > Paul2-# tablita.campoD =1 AND
> > Paul2-# tablita.campoE = 1
> > Paul2-# ORDER BY tablita.idDia , tablita.numHora;
> > iddia | numhora
> > -------+---------
> > 1 | 1
> > [...]
>
> Probé en PostgreSQL 8.1 sobre windows xp (sp2) y no
> existe el problema que mencionas, los datos salen
> correctamente ordenados..., por los datos que muestras
> al parecer no estás usando ORDER BY, digo esto,
> porque cuando quité esa parte de la consulta recién
> puedo reproducir tu *problema*.
>
> Saludos
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

Paolo Lopez escribió:

> > Envia el EXPLAIN ANALYZE, y verifica
>
> El EXPLAIN salé :
>
> Sort (cost=2.96..3.06 rows=40 width=8) (actual time=0.338..0.375
> rows=40 loops=1)
> Sort Key: iddia, numhora
> -> Seq Scan on tablita (cost=0.00..1.90 rows=40 width=8) (actual
> time=0.028..0.188 rows=40 loops=1)
> Filter: ((campoa = 1) AND (campob = 1) AND (campoc = 1) AND
> (campod = 1) AND (campoe = 1))
> Total runtime: 0.501 ms

Pero no pusiste el
SET enable_seqscan TO off;

que es importante para que vuelva a ejecutar usando el indice. Por
favor ponlo y haz la prueba nuevamente.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Paolo Lopez escribió:
> Gracias Alex por probar.
>
> Me sigue pareciendo raro este problema y encima en 2 maquinas y sobre
> el mismo query, para esta version 8.1.0 ( no es 8.1.1, ni 8.1.2, ni
> 8.1.3 )

Hmm, me pregunto si sera un bug corregido; la verdad, no creo. Pero por
favor pon 8.1.3 y prueba con eso.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro :

He seguido todos los pasos que me pediste , inlcuido el :

SET enable_seqscan TO off;

He estado pensando en lo mismo que me acabas de decir, pasar a la
ultima version 8.1.3 , y ver lo que pasa.

Probaré.

Thanks.

Paolo.

On 4/7/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Paolo Lopez escribió:
> > Gracias Alex por probar.
> >
> > Me sigue pareciendo raro este problema y encima en 2 maquinas y sobre
> > el mismo query, para esta version 8.1.0 ( no es 8.1.1, ni 8.1.2, ni
> > 8.1.3 )
>
> Hmm, me pregunto si sera un bug corregido; la verdad, no creo. Pero por
> favor pon 8.1.3 y prueba con eso.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>

Paolo Lopez escribió:
> Alvaro :
>
> He seguido todos los pasos que me pediste , inlcuido el :
>
> SET enable_seqscan TO off;

Imposible, porque si lo hubieras puesto y hubiera tenido efecto, el
costo de seqscan en el explain habria tenido un aumento grande (algo
como 100000000, puede que me equivoque en un par de ceros). Pero lo mas
probable es que, debido al alto costo del seqscan, hubiera preferido el
index scan (que es lo que me interesa ver en realidad).

Como estas ejecutando las consultas; usando pgAdmin? Si es asi, por
favor pruebalo usando psql.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On 4/7/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Paolo Lopez escribió:
> > Alvaro :
> >
> > He seguido todos los pasos que me pediste , inlcuido el :
> >
> > SET enable_seqscan TO off;
>
> Imposible, porque si lo hubieras puesto y hubiera tenido efecto, el
> costo de seqscan en el explain habria tenido un aumento grande (algo
> como 100000000, puede que me equivoque en un par de ceros). Pero lo mas
> probable es que, debido al alto costo del seqscan, hubiera preferido el
> index scan (que es lo que me interesa ver en realidad).
>
> Como estas ejecutando las consultas; usando pgAdmin? Si es asi, por
> favor pruebalo usando psql.
>

probando todo desde linea de comandos obtengo :

1er EXPLAIN ANALYZE :

Index Scan using tablita_pkey on tablita (cost=0.00..5.25 rows=40 width=8) (ac
tual time=0.032..0.164 rows=40 loops=1)
Index Cond: ((campoa = 1) AND (campob = 1) AND (campoc = 1) AND (campod = 1)
AND (campoe = 1))
Total runtime: 0.293 ms
(3 rows)

2do EXPLAIN ANALYZE :

Index Scan using tablita_pkey on tablita (cost=0.00..5.25 rows=40 width=8) (ac
tual time=0.202..0.337 rows=40 loops=1)
Index Cond: ((campoa = 1) AND (campob = 1) AND (campoc = 1) AND (campod = 1)
AND (campoe = 1))
Total runtime: 0.484 ms
(3 rows)

Y como se aprecia , esta vez no se efectua ordenamiento alguno.

Paolo.

Alvaro Herrera escribió:

>
> Me gustaria saber si alguien mas puede reproducir este problema en
> Windows.

Windows XP SP1
postgres=# select version();
version
------------------------------------------------------------------------------------------
PostgreSQL 8.1.1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special)
(1 fila)

Hasta esta expresion el ordenamiento lo hace mal en mi sistema:

CREATE TABLE tablita (
d int4 ,
e int4 ,
f int4 ,
dia int4 ,
primary key (d, e, f, dia)
);

INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 1);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 3);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 5);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 2);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 4);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 5);

select dia from tablita where d = 1 and e = 1 order by dia;

El resultado tanto en pgadmin como en la consola es:

dia
-----
1
3
5
2
4
5
(6 filas)

* Creo que he encontrado algo:

1.

Cambio los valores del campo 'e'

INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 1, 1);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 1, 3);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 1, 5);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 2, 2);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 2, 4);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 2, 5);

select dia from tablita where d = 1 and e = 2 order by dia;

El resultado es correcto:

dia
-----
1
2
3
4
5
5
(6 filas)

2.

Cambio los valores de los campos 'd' y 'e' y les vuelvo a poner un valor igual pero disntinto a '1':

INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 1, 1);
INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 1, 3);
INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 1, 5);
INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 2, 2);
INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 2, 4);
INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 2, 5);

select dia from tablita where d = 21512 and e = 21512 order by dia;

El resultado vuelve a ser incorrecto:
dia
-----
1
3
5
2
4
5
(6 filas)

3.

Pongo a 'd' y 'e' el mismo valor pero cambio la condicion where:

INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 1);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 3);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 5);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 2);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 4);
INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 5);

postgres=# select dia from tablita where d > 0 and e > 0 order by dia;
dia
-----
1
2
3
4
5
5
(6 filas)

El resultaso SI es correcto

4.

Mas pruebas cambiando el where:

postgres=# select dia from tablita where e = d and e = 1 order by dia;
dia
-----
1
3
5
2
4
5
(6 filas)
Incorrecto

postgres=# select dia from tablita where d between 1 and 1 and e between 1 and 1 order by dia;
dia
-----
1
2
3
4
5
5
(6 filas)
Correcto

postgres=# select dia from tablita where e = d and e > 0 order by dia;
dia
-----
1
2
3
4
5
5
(6 filas)
Correcto

Resumen:
Da la impresion que el fallo lo da unicamente cuando:
en el where estan las dos condiciones,
'd' y 'e' tienen el mismo valor
la clausula where utiliza el operador '=' para ambas condiciones

Saludos,

--
*****************************************
Oswaldo Hernández
oswaldo(at)soft-com(dot)es
*****************************************

This problem was reported by Paolo Lopez in pgsql-es-ayuda. Those who
can read spanish can probably get a better picture by seeing the
archives there. The initial post in the thread is this one:
http://archives.postgresql.org/pgsql-es-ayuda/2006-04/msg00095.php

This one, by Oswaldo Hernandez, has a detailed test case and more
exploration of problem conditions:

http://archives.postgresql.org/pgsql-es-ayuda/2006-04/msg00204.php

Apparently the point is that it fails when there is an index scan using
the primary key. So maybe the problem is that the index is corrupt.

I observe that Paolo was using 8.1.0 and Oswaldo 8.1.1. I can't
reproduce the problem here, but my system is Linux.

Oswaldo writes (translated):

> Windows XP SP1
> postgres=# select version();
> version
> ------------------------------------------------------------------------------------------
> PostgreSQL 8.1.1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2
> (mingw-special)
> (1 fila)
>
> Even with this expression I can reproduce the problem on my system:
>
> CREATE TABLE tablita (
> d int4 ,
> e int4 ,
> f int4 ,
> dia int4 ,
> primary key (d, e, f, dia)
> );
>
>
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 1);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 3);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 5);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 2);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 4);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 5);
>
> select dia from tablita where d = 1 and e = 1 order by dia;
>
> The result, both on pgadmin and psql is:
>
> dia
> -----
> 1
> 3
> 5
> 2
> 4
> 5
> (6 filas)
>
>
> * I think I've found something:
>
> 1. Change the values of column 'e':
>
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 1, 1);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 1, 3);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 1, 5);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 2, 2);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 2, 4);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 2, 5);
>
> select dia from tablita where d = 1 and e = 2 order by dia;
>
> The result is correct:
>
> dia
> -----
> 1
> 2
> 3
> 4
> 5
> 5
> (6 filas)
>
>
> 2. Change the values of columns 'd' and 'e' and put the same value to
> both, but different from '1':
>
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 1, 1);
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 1, 3);
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 1, 5);
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 2, 2);
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 2, 4);
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 2, 5);
>
> select dia from tablita where d = 21512 and e = 21512 order by dia;
>
> Result is wrong again:
> dia
> -----
> 1
> 3
> 5
> 2
> 4
> 5
> (6 filas)
>
> 3. Put the same value in 'd' and 'e', but change the where condition:
>
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 1);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 3);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 5);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 2);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 4);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 5);
>
> postgres=# select dia from tablita where d > 0 and e > 0 order by dia;
> dia
> -----
> 1
> 2
> 3
> 4
> 5
> 5
> (6 filas)
>
> The result is correct:
>
> 4.
>
> More tests changing WHERE conditions:
>
> postgres=# select dia from tablita where e = d and e = 1 order by dia;
> dia
> -----
> 1
> 3
> 5
> 2
> 4
> 5
> (6 filas)
> Wrong
>
> postgres=# select dia from tablita where d between 1 and 1 and e between 1
> and 1 order by dia;
> dia
> -----
> 1
> 2
> 3
> 4
> 5
> 5
> (6 filas)
> Correct
>
> postgres=# select dia from tablita where e = d and e > 0 order by dia;
> dia
> -----
> 1
> 2
> 3
> 4
> 5
> 5
> (6 filas)
> Correct
>
>
> Summary:
> It looks like the failure only presents itself when:
> en WHERE both conditions are present
> 'd' and 'e' have the same value
> the WHERE clause uses operator = for both conditions

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> I observe that Paolo was using 8.1.0 and Oswaldo 8.1.1.

This appears to be the same bug already fixed in 8.1.3:

2006-01-29 12:27 tgl

* src/: backend/optimizer/path/indxpath.c,
backend/optimizer/path/pathkeys.c, include/optimizer/paths.h
(REL8_1_STABLE): Fix code that checks to see if an index can be
considered to match the query's requested sort order. It was
assuming that build_index_pathkeys always generates a pathkey per
index column, which was not true if implied equality deduction had
determined that two index columns were effectively equated to each
other. Simplest fix seems to be to install an option that causes
build_index_pathkeys to support this behavior as well as the
original one. Per report from Brian Hirt.

regards, tom lane

Ok Oswaldo , gracias por tus pruebas. Son muy concluyentes.

Con respecto a mi version 8.1.0 he notado que cuando a "tablita" le
elimino el constraint de llave primaria, el ordenamiento se efectua
sin problemas. y cuando se le vuelve a poner llaves primarias, el
ordenamiento vuelve a ser erroneo.

Acabo de migrar a la version 8.1.3 , me sigue saliendo lo del guru
hint , pero el ordenamiento deseado se efectua sin ningun problema.

Paolo.

On 4/8/06, Oswaldo Hernández <listas(at)soft-com(dot)es> wrote:
> Alvaro Herrera escribió:
>
> >
> > Me gustaria saber si alguien mas puede reproducir este problema en
> > Windows.
>
> Windows XP SP1
> postgres=# select version();
> version
> ------------------------------------------------------------------------------------------
> PostgreSQL 8.1.1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special)
> (1 fila)
>
> Hasta esta expresion el ordenamiento lo hace mal en mi sistema:
>
> CREATE TABLE tablita (
> d int4 ,
> e int4 ,
> f int4 ,
> dia int4 ,
> primary key (d, e, f, dia)
> );
>
>
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 1);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 3);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 5);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 2);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 4);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 5);
>
> select dia from tablita where d = 1 and e = 1 order by dia;
>
> El resultado tanto en pgadmin como en la consola es:
>
> dia
> -----
> 1
> 3
> 5
> 2
> 4
> 5
> (6 filas)
>
>
> * Creo que he encontrado algo:
>
> 1.
>
> Cambio los valores del campo 'e'
>
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 1, 1);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 1, 3);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 1, 5);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 2, 2);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 2, 4);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 2, 2, 5);
>
> select dia from tablita where d = 1 and e = 2 order by dia;
>
> El resultado es correcto:
>
> dia
> -----
> 1
> 2
> 3
> 4
> 5
> 5
> (6 filas)
>
>
> 2.
>
> Cambio los valores de los campos 'd' y 'e' y les vuelvo a poner un valor igual pero disntinto a '1':
>
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 1, 1);
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 1, 3);
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 1, 5);
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 2, 2);
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 2, 4);
> INSERT INTO tablita (d, e, f, dia) VALUES (21512, 21512, 2, 5);
>
> select dia from tablita where d = 21512 and e = 21512 order by dia;
>
> El resultado vuelve a ser incorrecto:
> dia
> -----
> 1
> 3
> 5
> 2
> 4
> 5
> (6 filas)
>
> 3.
>
> Pongo a 'd' y 'e' el mismo valor pero cambio la condicion where:
>
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 1);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 3);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 1, 5);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 2);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 4);
> INSERT INTO tablita (d, e, f, dia) VALUES (1, 1, 2, 5);
>
> postgres=# select dia from tablita where d > 0 and e > 0 order by dia;
> dia
> -----
> 1
> 2
> 3
> 4
> 5
> 5
> (6 filas)
>
> El resultaso SI es correcto
>
> 4.
>
> Mas pruebas cambiando el where:
>
> postgres=# select dia from tablita where e = d and e = 1 order by dia;
> dia
> -----
> 1
> 3
> 5
> 2
> 4
> 5
> (6 filas)
> Incorrecto
>
> postgres=# select dia from tablita where d between 1 and 1 and e between 1 and 1 order by dia;
> dia
> -----
> 1
> 2
> 3
> 4
> 5
> 5
> (6 filas)
> Correcto
>
> postgres=# select dia from tablita where e = d and e > 0 order by dia;
> dia
> -----
> 1
> 2
> 3
> 4
> 5
> 5
> (6 filas)
> Correcto
>
>
> Resumen:
> Da la impresion que el fallo lo da unicamente cuando:
> en el where estan las dos condiciones,
> 'd' y 'e' tienen el mismo valor
> la clausula where utiliza el operador '=' para ambas condiciones
>
>
> Saludos,
>
> --
> *****************************************
> Oswaldo Hernández
> oswaldo(at)soft-com(dot)es
> *****************************************
>

Paolo Lopez escribió:

> Acabo de migrar a la version 8.1.3 , me sigue saliendo lo del guru
> hint , pero el ordenamiento deseado se efectua sin ningun problema.

Lo cual es perfectamente compatible con la observacion de que el bug fue
corregido en 8.1.3, y que tal como te habia dicho inicialmente, el bug
no tiene nada que ver con el VACUUM.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Visto el problema y la solucion a ello, solo me queda agradecer a
todos los que contribuyeron en su esclarecimiento y solucion.

Mencion especial a Alvaro cuya participacion fue decisiva en la
solucion del mismo.

Muchas gracias a todos.

Atentamente.

Paolo.

On 4/8/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Paolo Lopez escribió:
>
> > Acabo de migrar a la version 8.1.3 , me sigue saliendo lo del guru
> > hint , pero el ordenamiento deseado se efectua sin ningun problema.
>
> Lo cual es perfectamente compatible con la observacion de que el bug fue
> corregido en 8.1.3, y que tal como te habia dicho inicialmente, el bug
> no tiene nada que ver con el VACUUM.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>

On 4/8/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Paolo Lopez escribió:
>
> > Acabo de migrar a la version 8.1.3 , me sigue saliendo lo del guru
> > hint , pero el ordenamiento deseado se efectua sin ningun problema.
>
> Lo cual es perfectamente compatible con la observacion de que el bug fue
> corregido en 8.1.3, y que tal como te habia dicho inicialmente, el bug
> no tiene nada que ver con el VACUUM.
>

Solo una observacion para Paolo... evita las primeras versiones de
todo release salvo que sea para pruebas, usar una version 8.x.0 es
buscar problemas...

de todos modos gracias por el reporte y si te ocurre algon 8.1.3 no
dudes en reportarlo...

--
Atentamente,
Jaime Casanova

"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
Randal L. Schwartz