Re: result set offset -limit que con una query no se encuentra

Gente, estoy con pgsql8.4 beta1 y me pasa lo siguiente:

select * from datos limit 1 offset 167914;

texto | entero2 | entero4 |
entero8 | float |
fecha | tiempo | ztiempo
| ip
----------------------------------+---------+-----------+---------------------+------------------+--
----------+----------------------------+-------------------------------+-----------------
18e4745193af9e699014edf21bb86e85 | 1103 | -24471577 |
2064845141951966355 | 305.908181944396 | 2
009-05-08 | 2009-05-08 12:02:28.195846 | 2009-05-08 12:02:28.195846-03
| 34.132.9.141/32
(1 row)

parapruebas=# select * from datos limit 1 offset 167914;
parapruebas=# select entero8, float from datos limit 1 offset 167914;
entero8 | float
---------------------+------------------
4201021101379964833 | 529.568756118882
(1 row)

parapruebas=# select entero4, entero8, float from datos limit 1 offset 167914;
entero4 | entero8 | float
-----------+---------------------+------------------
153051873 | -156940279311698037 | 536.905172820669
(1 row)

No hay campos con valores nulos.

Si miran bien los valores son distintos... :O

Lo único que cree fue una tabla heredada en memoria...
CREATE TABLE datos_ram() INHERITS (datos) TABLESPACE ramy;

QUERY PLAN

----------------------------------------------------------------------------------------------------
-----------------------------
Limit (cost=4013.49..4013.52 rows=1 width=20) (actual
time=2969.851..2969.853 rows=1 loops=1)
-> Result (cost=0.00..4028.36 rows=168536 width=20) (actual
time=0.022..2492.754 rows=167915 lo
ops=1)
-> Append (cost=0.00..4028.36 rows=168536 width=20) (actual
time=0.017..1515.252 rows=167
915 loops=1)
-> Seq Scan on datos (cost=0.00..4012.36 rows=167936
width=20) (actual time=0.011..
551.485 rows=167915 loops=1)
-> Seq Scan on datos_ram datos (cost=0.00..16.00
rows=600 width=20) (never executed
)
Total runtime: 2969.936 ms
(6 rows)

Borré la tabla heredada y los resultados son estos:

parapruebas=# select entero4, entero8, float from datos limit 1 offset 167914;
entero4 | entero8 | float
-----------+--------------------+------------------o8, float from
datos limit 1 o
-17054690 | 174907075697610278 | 245.718919624574
(1 row)

parapruebas=# select entero8, float from datos limit 1 offset 167914;
entero8 | float
---------------------+------------------
1939054161121250427 | 403.497909076978
(1 row)

No hay indices de ningun tipo.

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member

2009/5/8 Emanuel Calvo Franco <postgres(dot)arg(at)gmail(dot)com>:
> Gente, estoy con pgsql8.4 beta1 y me pasa lo siguiente:
>
> select * from datos limit 1 offset 167914;
>
>              texto               | entero2 |  entero4  |
> entero8       |      float       |
>  fecha    |           tiempo           |            ztiempo
> |       ip
> ----------------------------------+---------+-----------+---------------------+------------------+--
> ----------+----------------------------+-------------------------------+-----------------
>  18e4745193af9e699014edf21bb86e85 |    1103 | -24471577 |
> 2064845141951966355 | 305.908181944396 | 2
> 009-05-08 | 2009-05-08 12:02:28.195846 | 2009-05-08 12:02:28.195846-03
> | 34.132.9.141/32
> (1 row)
>
> parapruebas=# select * from datos limit 1 offset 167914;
> parapruebas=# select entero8, float from datos limit 1 offset 167914;
>       entero8       |      float
> ---------------------+------------------
>  4201021101379964833 | 529.568756118882
> (1 row)
>
> parapruebas=# select entero4, entero8, float from datos limit 1 offset 167914;
>  entero4  |       entero8       |      float
> -----------+---------------------+------------------
>  153051873 | -156940279311698037 | 536.905172820669
> (1 row)
>
>
> No hay campos con valores nulos.
>
> Si miran bien los valores son distintos... :O
>
>
> Lo único que cree fue una tabla heredada en memoria...
> CREATE TABLE datos_ram() INHERITS (datos) TABLESPACE ramy;
>
>                                                           QUERY PLAN
>
> ----------------------------------------------------------------------------------------------------
> -----------------------------
>  Limit  (cost=4013.49..4013.52 rows=1 width=20) (actual
> time=2969.851..2969.853 rows=1 loops=1)
>   ->  Result  (cost=0.00..4028.36 rows=168536 width=20) (actual
> time=0.022..2492.754 rows=167915 lo
> ops=1)
>         ->  Append  (cost=0.00..4028.36 rows=168536 width=20) (actual
> time=0.017..1515.252 rows=167
> 915 loops=1)
>               ->  Seq Scan on datos  (cost=0.00..4012.36 rows=167936
> width=20) (actual time=0.011..
> 551.485 rows=167915 loops=1)
>               ->  Seq Scan on datos_ram datos  (cost=0.00..16.00
> rows=600 width=20) (never executed
> )
>  Total runtime: 2969.936 ms
> (6 rows)
>
>
> Borré la tabla heredada y los resultados son estos:
>
> parapruebas=# select entero4, entero8, float from datos limit 1 offset 167914;
>  entero4  |      entero8       |      float
> -----------+--------------------+------------------o8, float from
> datos limit 1 o
>  -17054690 | 174907075697610278 | 245.718919624574
> (1 row)
>
> parapruebas=# select entero8, float from datos limit 1 offset 167914;
>       entero8       |      float
> ---------------------+------------------
>  1939054161121250427 | 403.497909076978
> (1 row)
>
>
>
> No hay indices de ningun tipo.
>

Agrego:

Column | Type | Modifiers
---------+-----------------------------+------------------------------------------------------------
texto | text | default md5((random())::text)
entero2 | smallint | default
(rpad((hashtext((random())::text))::text, 4))::smallint
entero4 | integer | default
(lpad(((hashtext((random())::text))::text ||
replace((hashtext((random())::text))::text, '-'::text, ''::text)),
9))::integer
entero8 | bigint | default
(rpad(((hashtext((random())::text))::text ||
replace((hashtext((random())::text))::text, '-'::text, ''::text)),
19))::bigint
float | double precision | default ((random() *
(1000)::double precision) + random())
fecha | date | default (now())::date
tiempo | timestamp without time zone | default now()
ztiempo | timestamp with time zone | default now()
ip | cidr | default
((((((((pg_round_random_range(0, 255))::text || '.'::text) ||
(pg_round_random_range(0, 255))::text) || '.'::text) || (pg_round_

Estos son los datos de la tabla 'datos'.

La info se inserta con 'insert into datos default values'.

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member

Emanuel Calvo Franco escribió:

> select * from datos limit 1 offset 167914;

Debes especificar ORDER BY, de lo contrario una consulta con
LIMIT/OFFSET no necesariamente entregará resultados que sean siempre
consistentes.

--
Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257
"Puedes elegir el color de tu auto -- siempre y cuando sea negro."
(Henry Ford)

Alvaro,

Podrias explicar un poco mas eso? Me dejo algo confundido.

Gracias,
Guido

2009/5/8 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>:
> Emanuel Calvo Franco escribió:
>
>> select * from datos limit 1 offset 167914;
>
> Debes especificar ORDER BY, de lo contrario una consulta con
> LIMIT/OFFSET no necesariamente entregará resultados que sean siempre
> consistentes.
>
>
> --
> Alvaro Herrera      Valdivia, Chile           Geotag: -39,815 -73,257
> "Puedes elegir el color de tu auto -- siempre y cuando sea negro."
>                                                 (Henry Ford)
> --
> TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
>

Guido Barosio escribió:
> Alvaro,
>
> Podrias explicar un poco mas eso? Me dejo algo confundido.

Imagina que tienes una tabla que está ordenada fisicamente así:

3
2
1

En cambio el índice está (obviamente) ordenado físicamente así:
1
2
3

Si haces la siguiente consulta puedes obtener resultados distintos:
select * from tab limit 1

si es que la consulta va directo a la tabla (seqscan) o si usa el
índice. Retornará la primera tupla que encuentre; en seqscan será el 3,
en el indexscan será el 1.

Obviamente si tienes más de un índice, la cosa se pone aún más
complicada. Creo que HOT (en 8.3) puede ponerlo aún más difícil.

--
Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)

Alvaro Herrera escribió:

> Obviamente si tienes más de un índice, la cosa se pone aún más
> complicada. Creo que HOT (en 8.3) puede ponerlo aún más difícil.

Otra cosa es que si existen UPDATE, INSERT o DELETE operando en
paralelo, los resultados también se alteran.

--
Alvaro Herrera http://www.amazon.com/gp/registry/3BP7BYG9PUGI8
"El hombre nunca sabe de lo que es capaz hasta que lo intenta" (C. Dickens)

Comprendia esto, pero no lo relacione en ningun momento con OFFSET y
su trabajo; disculpas y gracias!

gb.-

2009/5/8 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>:
> Guido Barosio escribió:
>> Alvaro,
>>
>>      Podrias explicar un poco mas eso? Me dejo algo confundido.
>
> Imagina que tienes una tabla que está ordenada fisicamente así:
>
> 3
> 2
> 1
>
> En cambio el índice está (obviamente) ordenado físicamente así:
> 1
> 2
> 3
>
> Si haces la siguiente consulta puedes obtener resultados distintos:
> select * from tab limit 1
>
> si es que la consulta va directo a la tabla (seqscan) o si usa el
> índice.  Retornará la primera tupla que encuentre; en seqscan será el 3,
> en el indexscan será el 1.
>
> Obviamente si tienes más de un índice, la cosa se pone aún más
> complicada.  Creo que HOT (en 8.3) puede ponerlo aún más difícil.
>
> --
> Alvaro Herrera      Valdivia, Chile           Geotag: -39,815 -73,257
> "The Gord often wonders why people threaten never to come back after they've
> been told never to return" (www.actsofgord.com)
>

El día 8 de mayo de 2009 14:11, Guido Barosio <gbarosio(at)gmail(dot)com> escribió:
> Comprendia esto, pero no lo relacione en ningun momento con OFFSET y
> su trabajo; disculpas y gracias!
>
> gb.-
>
> 2009/5/8 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>:
>> Guido Barosio escribió:
>>> Alvaro,
>>>
>>>      Podrias explicar un poco mas eso? Me dejo algo confundido.
>>
>> Imagina que tienes una tabla que está ordenada fisicamente así:
>>
>> 3
>> 2
>> 1
>>
>> En cambio el índice está (obviamente) ordenado físicamente así:
>> 1
>> 2
>> 3
>>
>> Si haces la siguiente consulta puedes obtener resultados distintos:
>> select * from tab limit 1
>>
>> si es que la consulta va directo a la tabla (seqscan) o si usa el
>> índice.  Retornará la primera tupla que encuentre; en seqscan será el 3,
>> en el indexscan será el 1.
>>
>> Obviamente si tienes más de un índice, la cosa se pone aún más
>> complicada.  Creo que HOT (en 8.3) puede ponerlo aún más difícil.
>>

Alvaro:
- No hay indices.
- No hay actualizaciones desde otros clientes. Es una base local
corriendo en mi maquina.

Por eso pegue el Explain, para que vean que utiliza Seq scan.

Sin embargo... más allá que no que se ordene con 'order by':
tiene sentido que encuentre tuplas distintas cuando realiza un
seq scan? Si recorre físicamente una tabla secuencialmente, no
es lógico que recorra la misma cantidad de registros?

si le pongo 'order by' entrega bien los datos.

parapruebas=# select oid, entero4, entero8 from datos limit 10 offset 30100;
oid | entero4 | entero8
-------+-----------+---------------------
60078 | -59181993 | 1605077023306511927
60079 | 154944548 | 1610330835152072023
60080 | 191764350 | 3296163411778718507
60081 | 375505221 | 1814411661188540179
60082 | -68362750 | -212276557510527695
60083 | 849502356 | 776642986831459179
60084 | 182879742 | 10495537526787819
60085 | -17971849 | -840495673129543340
60086 | -16315064 | -474485986316111726
60087 | 226529751 | -102773574715130420
(10 rows)

parapruebas=# select oid, entero4, entero8 from datos limit 10 offset 30100;
oid | entero4 | entero8
-------+-----------+---------------------
89198 | 778966065 | -127992652379536681
89199 | 848652228 | 493105858113764792
89200 | -10664072 | 1149036300154724266
89201 | 202268640 | 7201425031377410606
89202 | -15172548 | -170760529746359766
89203 | 564061426 | -151193946178778172
89204 | 152393718 | -209584241918183851
89205 | 142385773 | 123532171547284235
89206 | 769425938 | -104161792261293172
89207 | 213079572 | -480192359206568708
(10 rows)

parapruebas=# explain analyze select oid, entero4, entero8 from datos
limit 10 offset 30100;
QUERY PLAN

----------------------------------------------------------------------------------------------------
---------------
Limit (cost=719.06..719.29 rows=10 width=16) (actual
time=165.882..165.947 rows=10 loops=1)
-> Seq Scan on datos (cost=0.00..4128.00 rows=172800 width=16)
(actual time=0.012..91.116 rows=30110 loops=1)
Total runtime: 166.007 ms
(3 rows)

QUERY PLAN

----------------------------------------------------------------------------------------------------
----------------
Limit (cost=719.06..719.29 rows=10 width=16) (actual
time=187.856..187.920 rows=10 loops=1)
-> Seq Scan on datos (cost=0.00..4128.00 rows=172800 width=16)
(actual time=0.050..111.205 rows
=30110 loops=1)
Total runtime: 187.982 ms
(3 rows)

Los explain son para la misma consulta 2 veces.
Verbose no me tira mucho más.

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member

Emanuel Calvo Franco escribió:

> Alvaro:
> - No hay indices.
> - No hay actualizaciones desde otros clientes. Es una base local
> corriendo en mi maquina.

Autovacuum está activo?

> parapruebas=# explain analyze select oid, entero4, entero8 from datos
> limit 10 offset 30100;
> QUERY PLAN
>
> ----------------------------------------------------------------------------------------------------
> ---------------
> Limit (cost=719.06..719.29 rows=10 width=16) (actual
> time=165.882..165.947 rows=10 loops=1)
> -> Seq Scan on datos (cost=0.00..4128.00 rows=172800 width=16)
> (actual time=0.012..91.116 rows=30110 loops=1)
> Total runtime: 166.007 ms
> (3 rows)
>
> QUERY PLAN
>
> ----------------------------------------------------------------------------------------------------
> ----------------
> Limit (cost=719.06..719.29 rows=10 width=16) (actual
> time=187.856..187.920 rows=10 loops=1)
> -> Seq Scan on datos (cost=0.00..4128.00 rows=172800 width=16)
> (actual time=0.050..111.205 rows
> =30110 loops=1)
> Total runtime: 187.982 ms
> (3 rows)
>
> Los explain son para la misma consulta 2 veces.

¿Qué tanto rato pasó entre un explain y el siguiente? La única
explicación que se me ocurre para que te entregue planes con
estimaciones distintas es que se ejecutó ANALYZE entre medio
(posiblemente autovacuum).

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"Prefiero omelette con amigos que caviar con tontos"
(Alain Nonnet)

El día 8 de mayo de 2009 15:25, Alvaro Herrera
<alvherre(at)alvh(dot)no-ip(dot)org> escribió:
> Emanuel Calvo Franco escribió:
>
>> Alvaro:
>> - No hay indices.
>> - No hay actualizaciones desde otros clientes. Es una base local
>> corriendo en mi maquina.
>
> Autovacuum está activo?
>

Estaba. Pero lo desactive y volví a probar.
sucede lo mismo.

>> parapruebas=# explain analyze select oid, entero4, entero8 from datos
>> limit 10 offset 30100;
>>                                                     QUERY PLAN
>>
>> ----------------------------------------------------------------------------------------------------
>> ---------------
>>  Limit  (cost=719.06..719.29 rows=10 width=16) (actual
>> time=165.882..165.947 rows=10 loops=1)
>>    ->  Seq Scan on datos  (cost=0.00..4128.00 rows=172800 width=16)
>> (actual time=0.012..91.116 rows=30110 loops=1)
>>  Total runtime: 166.007 ms
>> (3 rows)
>>
>>                                                     QUERY PLAN
>>
>> ----------------------------------------------------------------------------------------------------
>> ----------------
>>  Limit  (cost=719.06..719.29 rows=10 width=16) (actual
>> time=187.856..187.920 rows=10 loops=1)
>>    ->  Seq Scan on datos  (cost=0.00..4128.00 rows=172800 width=16)
>> (actual time=0.050..111.205 rows
>> =30110 loops=1)
>>  Total runtime: 187.982 ms
>> (3 rows)
>>
>> Los explain son para la misma consulta 2 veces.
>
> ¿Qué tanto rato pasó entre un explain y el siguiente?  La única
> explicación que se me ocurre para que te entregue planes con
> estimaciones distintas es que se ejecutó ANALYZE entre medio
> (posiblemente autovacuum).
>

Inmediatamente.

parapruebas=# select oid, entero8 from datos limit 1 offset 10000;
oid | entero8
-------+--------------------
35498 | 193916708866014934
(1 row)

parapruebas=# select oid, entero8 from datos limit 1 offset 10000;
oid | entero8
-------+---------------------
44458 | -902052893157845017
(1 row)

las ejecuto ambas seguidas y siempre traen distintas.

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member

El día 8 de mayo de 2009 15:35, Emanuel Calvo Franco
<postgres(dot)arg(at)gmail(dot)com> escribió:
> El día 8 de mayo de 2009 15:25, Alvaro Herrera
> <alvherre(at)alvh(dot)no-ip(dot)org> escribió:
>> Emanuel Calvo Franco escribió:
>>
>>> Alvaro:
>>> - No hay indices.
>>> - No hay actualizaciones desde otros clientes. Es una base local
>>> corriendo en mi maquina.
>>
>> Autovacuum está activo?
>>
>
> Estaba. Pero lo desactive y volví a probar.
> sucede lo mismo.
>
>> ¿Qué tanto rato pasó entre un explain y el siguiente?  La única
>> explicación que se me ocurre para que te entregue planes con
>> estimaciones distintas es que se ejecutó ANALYZE entre medio
>> (posiblemente autovacuum).
>>
>
> Inmediatamente.
>
> parapruebas=# select oid, entero8 from datos limit 1 offset 10000;
>  oid  |      entero8
> -------+--------------------
>  35498 | 193916708866014934
> (1 row)
>
> parapruebas=# select oid, entero8 from datos limit 1 offset 10000;
>  oid  |       entero8
> -------+---------------------
>  44458 | -902052893157845017
> (1 row)
>
> las ejecuto ambas seguidas y siempre traen distintas.
>
>

En 8.3.5 sucede lo mismo con esta tabla (probe en un
servidor totalmente aparte.

[http://skyline.dbai.tuwien.ac.at/]

select * from datos limit 1 offset 100000

Pero lo extraño que es en esta tabla nomás (tiene aprox. 167000
registros y pesa 15 MB aprox).
Probé en otra tabla de otra base y esa misma consulta no
me da este error (si se puede considerar un error).

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member

Emanuel Calvo Franco escribió:

> En 8.3.5 sucede lo mismo con esta tabla (probe en un
> servidor totalmente aparte.
>
> [http://skyline.dbai.tuwien.ac.at/]
>
> select * from datos limit 1 offset 100000
>
> Pero lo extraño que es en esta tabla nomás (tiene aprox. 167000
> registros y pesa 15 MB aprox).
> Probé en otra tabla de otra base y esa misma consulta no
> me da este error (si se puede considerar un error).

Hmm, esto es Postgres o es una versión modificada?

(No se me ocurre ninguna explicación para este comportamiento en
Postgres, pero no puedo investigarlo en este momento)

--
Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257
"In a specialized industrial society, it would be a disaster
to have kids running around loose." (Paul Graham)

El día 8 de mayo de 2009 17:50, Alvaro Herrera
<alvherre(at)alvh(dot)no-ip(dot)org> escribió:
> Emanuel Calvo Franco escribió:
>
>> En 8.3.5 sucede lo mismo con esta tabla (probe en un
>> servidor totalmente aparte.
>>
>> [http://skyline.dbai.tuwien.ac.at/]
>>
>> select * from datos limit 1 offset 100000
>>
>> Pero lo extraño que es en esta tabla nomás (tiene aprox. 167000
>> registros y pesa 15 MB aprox).
>> Probé en otra tabla de otra base y esa misma consulta no
>> me da este error (si se puede considerar un error).
>
> Hmm, esto es Postgres o es una versión modificada?
>
> (No se me ocurre ninguna explicación para este comportamiento en
> Postgres, pero no puedo investigarlo en este momento)

Se podría considerar un bug?

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member

Emanuel Calvo Franco escribió:
> El día 8 de mayo de 2009 17:50, Alvaro Herrera
> <alvherre(at)alvh(dot)no-ip(dot)org> escribió:
> > Emanuel Calvo Franco escribió:
> >
> >> En 8.3.5 sucede lo mismo con esta tabla (probe en un
> >> servidor totalmente aparte.
> >>
> >> [http://skyline.dbai.tuwien.ac.at/]
> >>
> >> select * from datos limit 1 offset 100000
> >>
> >> Pero lo extraño que es en esta tabla nomás (tiene aprox. 167000
> >> registros y pesa 15 MB aprox).
> >> Probé en otra tabla de otra base y esa misma consulta no
> >> me da este error (si se puede considerar un error).
> >
> > Hmm, esto es Postgres o es una versión modificada?
> >
> > (No se me ocurre ninguna explicación para este comportamiento en
> > Postgres, pero no puedo investigarlo en este momento)
>
>
> Se podría considerar un bug?

Lo dudo, pero no respondiste mi pregunta.

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"I'm impressed how quickly you are fixing this obscure issue. I came from
MS SQL and it would be hard for me to put into words how much of a better job
you all are doing on [PostgreSQL]."
Steve Midgley, http://archives.postgresql.org/pgsql-sql/2008-08/msg00000.php

El día 8 de mayo de 2009 18:01, Alvaro Herrera
<alvherre(at)alvh(dot)no-ip(dot)org> escribió:
> Emanuel Calvo Franco escribió:
>> El día 8 de mayo de 2009 17:50, Alvaro Herrera
>> <alvherre(at)alvh(dot)no-ip(dot)org> escribió:
>> > Emanuel Calvo Franco escribió:
>> >
>> >> En 8.3.5 sucede lo mismo con esta tabla (probe en un
>> >> servidor totalmente aparte.
>> >>
>> >> [http://skyline.dbai.tuwien.ac.at/]
>> >>
>> >> select * from datos limit 1 offset 100000
>> >>
>> >> Pero lo extraño que es en esta tabla nomás (tiene aprox. 167000
>> >> registros y pesa 15 MB aprox).
>> >> Probé en otra tabla de otra base y esa misma consulta no
>> >> me da este error (si se puede considerar un error).
>> >
>> > Hmm, esto es Postgres o es una versión modificada?
>> >
>> > (No se me ocurre ninguna explicación para este comportamiento en
>> > Postgres, pero no puedo investigarlo en este momento)
>>
>>
>> Se podría considerar un bug?
>
> Lo dudo, pero no respondiste mi pregunta.
>

Ah, perdón...
No no, (o sea la del link si) pero en la local es
la normal.

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member

El día 8 de mayo de 2009 18:12, Emanuel Calvo Franco
<postgres(dot)arg(at)gmail(dot)com> escribió:
> El día 8 de mayo de 2009 18:01, Alvaro Herrera
> <alvherre(at)alvh(dot)no-ip(dot)org> escribió:
>> Emanuel Calvo Franco escribió:
>> Lo dudo, pero no respondiste mi pregunta.
>>
>
>
> Ah, perdón...
> No no, (o sea la del link si) pero en la local es
> la normal.
>

FYI
Tom me dijo que ponga en off synchronize_seqscans.
Resultó. :)

Te comento por si no seguias la lista general.

Buen finde, alvaro

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member