Re: Performance von LIMIT und OFFSET

Alvar Freude schrob:

> -- Kretschmer Andreas <andreas_kretschmer(at)despammed(dot)com> wrote:
>
>> Die Tabelle wird so dolle groß nicht werden, vielleicht 1000 Datensätze
>> pro Jahr. Allerdings ca. 15 Fremdschlüssel, die aufzulösen sind.
>
> aber die sind ja nur beim Schreiben relevant. Beim Lesen ist es egal, auf
> wieviele andere Tabellen die einzelnen Spalten verweisen und evtl. dort
> Indexe angelegt werden (mal abgesehen von Nebeneffekten aufgrund von
> Cache-Nutzung beim Schreiben).

"die aufzulösen sind" hört sich allerdings schwer nach Joins an.

> Bei ein paar tausend Datensätzen würde ich nun schätzen, dass in der
> Praxis kaum ein merklicher Perfermance-Unterschied auftritt.

Es gibt gute Gründe gegen einen Cursor. Wenn z.B. der User via CGI
blättert, müßte man einen ziemlichen Aufwand betreiben, um einen
Cursor nutzen zu können. Bei einer gemeinen Verbindung schreit
blättern aber geradezu nach einem Cursor.

Gut möglich, daß bei einer passenden Abfrage subjektiv kein
Unterschied festgestellt wird; trotzdem wird unnötig Rechenzeit
verbraten. Zur Illustration hab' ich meinen /usr/share/dict/words-
Testfall vom Freitag mal mit \timing angehängt.

Gruß
Andreas

--8<---------------cut here---------------start------------->8---
scratch=# create table words(w text);
CREATE TABLE
scratch=# \copy words from /usr/share/dict/words
\.
scratch=# \timing
Timing is on.
scratch=# declare foo cursor for select w from words;
DECLARE CURSOR
Time: 9.180 ms
scratch=# move 10000 in foo;
MOVE 10000
Time: 597.038 ms
scratch=# fetch 1 from foo;
Time: 3.907 ms
scratch=# fetch 1 from foo;
Time: 3.920 ms
scratch=# fetch 1 from foo;
Time: 3.828 ms
scratch=# select w from words limit 1 offset 10000;
Time: 497.621 ms
scratch=# select w from words limit 1 offset 10001;
Time: 519.507 ms
scratch=# select w from words limit 1 offset 10002;
Time: 507.690 ms
scratch=# select w from words limit 1 offset 10003;
Time: 503.374 ms
--8<---------------cut here---------------end--------------->8---