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

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