From: | PostgreSQL - Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> |
---|---|
To: | Volker Sievert <sievert(at)molgen(dot)mpg(dot)de> |
Cc: | pgsql-de-allgemein(at)postgresql(dot)org |
Subject: | Re: [pgsql-de-allgemein] [pgsql-de-allgemein] Performance bricht abrupt ein bei großen Ergebnismengen |
Date: | 2011-09-30 19:43:50 |
Message-ID: | EE32D0B9-1B47-41AC-BC44-885ADE2BF565@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-de-allgemein |
hallo ...
ich habe einfach mal ein kleines beispielhaftes ding rauskopiert:
du siehst einen index scan, der seine daten nur zu einem teil aus dem postgres shared buffer bezieht.je nach config kann das durchaus bedeuten, dass du eine menge random I/O hast und random I/O ist so ziemlich das teuerste, was es im database business gibt. auch das stecken von mehr disks wird in so einem fall nur bedingt helfen, weil du schlichtweg für einen ganzen haufen von blöcken disk seeks aufgabelst.
Merge Cond: (s1.id = aa.vdj)
Buffers: shared hit=257186 read=691402, temp written=21429
-> Index Scan using biosequences_pkey on sequences s1 (cost=0.00..1173213.59 rows=23722060 width=103) (actual time=0.010..121574.630 rows=23722059 loops=1)
Buffers: shared hit=257180 read=632021
wenn du schaust: man sieht das auch bei "actual time" ... in diesen scans entsteht einfach die meiste zeit.
um einen vergleich zu haben, kannst du mal vor der query versuchen, die random I/O für den optimizer zu verteuern - vielleicht benötigst du ja genug daten, dass sich ein seq scan schon rechnet.
das geht so:
SET random_page_cost TO 20;
dann noch mal die query.
gut möglich, dass bei ausreichend hohen random_page_costs statt dem index ein seq -> sort oder so raus kommt, der dann in summe schneller ist.
und; mehr ram + höhere shared buffers wären auch ein versuch wert.
lg,
hans
On Sep 30, 2011, at 3:28 PM, Volker Sievert wrote:
> Merge Cond: (s1.id = aa.vdj)
> Buffers: shared hit=257186 read=691402, temp written=21429
> -> Index Scan using biosequences_pkey on sequences s1 (cost=0.00..1173213.59 rows=23722060 width=103) (actual time=0.010..121574.630 rows=23722059 loops=1)
> Buffers: shared hit=257180 read=632021
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas 'ads' Scherbaum | 2011-10-03 09:48:21 | == Wöchentlicher PostgreSQL Newsletter - 02. Oktober 2011 == |
Previous Message | Michael Renner | 2011-09-30 14:29:54 | Re: [pgsql-de-allgemein] Re: [pgsql-de-allgemein] Re: [pgsql-de-allgemein] Performance bricht abrupt ein bei großen Ergebnismengen |