Re: [pgsql-de-allgemein] [pgsql-de-allgemein] Performance bricht abrupt ein bei großen Ergebnismengen

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

In response to

Browse pgsql-de-allgemein by date

  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