Dimitrios Apostolou <ji...@gmx.net> writes:
> The question is why this simple query is taking so long to complete.
Do you get the same 10 rows when you repeat the command?
On the basis of the limited info you provided, I'm going to guess that
(1) there are huge subranges of the table containing no live rows,
so that a seqscan might have to pass over many blocks before it finds
some to return;
(2) once you do reach an area having live rows, the next SELECT picks
up scanning in that same area due to the effects of
"synchronize_seqscans", so you get immediate answers until you reach
the next desert of dead tuples.
If turning synchronize_seqscans off changes the behavior, that'd
be a good clue that this is the right theory. As for a real fix,
it might be time for a VACUUM FULL or CLUSTER on that table.
regards, tom lane
