El día 8 de mayo de 2009 14:11, Guido Barosio <gbaro...@gmail.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 <alvhe...@alvh.no-ip.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
--
TIP 1: para suscribirte y desuscribirte, visita 
http://archives.postgresql.org/pgsql-es-ayuda

Responder a