Dimitrios Apostolou <jimis@xxxxxxx> writes: > On Tue, 31 Jan 2023, Tom Lane wrote: >> Do you get the same 10 rows when you repeat the command? > Yes. Just tested with both cold and hot caches. The first 10 rows are > exactly the same, either they return slowly or immediately. Hm. I don't recall exactly how synchronize_seqscans works --- it definitely changes the point in the table where a seqscan begins scanning, but I don't remember where/when that point gets updated (and I'm too lazy to go look). This result suggests that the first query advances the table's sync start point to someplace a bit before the first live tuple, not after all the returned tuples as I'd been thinking. It might be that the start point is always the beginning of a block, so that if you fetch only a few tuples that are all in the same block then the next attempt will re-fetch them. If you increase the LIMIT to say 1000, does the behavior (with synchronize_seqscans on) change? >> If turning synchronize_seqscans off changes the behavior, that'd >> be a good clue that this is the right theory. > Turning it off makes the query slow no matter how many times I re-run it. OK, well that's enough of a smoking gun to say that it is the sync start point that's the relevant state, and not the contents of your data caches at all. Anyway, the follow-on discussion makes it clear that you do indeed have a badly bloated table, and fixing that situation should fix this performance issue. regards, tom lane
