Problema Order By en PosgreSQL 8.1

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.

Show quoted text

On 4/5/06, Alvaro Herrera <alvherre@commandprompt.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.

Show quoted text

On 4/6/06, Jaime Casanova <systemguards@gmail.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.

Show quoted text

On 4/7/06, Alvaro Herrera <alvherre@commandprompt.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@gmail.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.

Show quoted text

On 4/7/06, Alex Concha <xkn0wn@yahoo.com> wrote:

Hola,

--- Paolo Lopez <murphyperu@gmail.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.

Show quoted text

On 4/7/06, Alvaro Herrera <alvherre@commandprompt.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@commandprompt.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.