abfragen auf tabelle langsam

von full war eben keine rede :slight_smile:

wenn ich einen relevanten test mache, komme ich auf etwa das gleiche ergebnis…es ist 3 mal langsamer als auf der anderen tabelle

http://www.pg-forum.de/sql/3882-abfragen-auf-tabelle-langsam-post20977.html#poststop

hmm tatsaechlich

wenn ich einen relevanten test mache, komme ich auf etwa das gleiche ergebnis…es ist 3 mal langsamer als auf der anderen tabelle

naja - wenn in den abfragen full-table-scans vorkommen wundert das nicht …

prüf das noch mal nach dem vacuum full

Wie sieht denn ein explain analyse von diesem ‘relevanten test’ aus?

Andreas

PostgreSQL aufräumen - VACUUM | PostgreSQL Werkstatt

Jetzt sind die abfragen ‘schnell’ ! danke leute.

anpassen von max_fsm_pages + vacuum full habens gebracht.

akretschmer: stell mal eine Rechnung, addiere eine Position für das Nicht-beachten unserer Hinweise :wink:

:slight_smile: ads sagte noch

Da steht doch schon mal etwas, befolg den Hinweis bitte mal.
Also nicht das VACUUM FULL, sondern die Konfiguration anpassen.

also habe ich NICHT das vacuum full gemacht

An der Stelle solltest du auch erst mal nur die dringend notwendige Anpassung der Konfiguration nachholen. Andernfalls hat die Datenbank zu wenig Platz, um all deinen freien Speicherplatz zu verfolgen. Das hat die Ausgabe auch deutlich gesagt.

ihr habt ihm wirklich gesagt, dass er nicht das vacuum full machen soll/braucht … dabei war dies hier durchaus nützlich weil es auch guenstigerweise die blöcke zusammenschiebt → geringere fragmentierung → weniger spurwechsel → viel schneller

naja egal

diese fsm-dings-pages dienen ja nur dazu freie slots zu markieren … optimiert wird dadurch an der table selbst ja nix …

Das Problem mit VACUUM FULL ist, dass es nur für kurze Zeit hilft. Irgendwann erodiert die Tabelle wieder und dann steht man vor den gleichen Problem.
Außerdem blockiert VACUUM FULL die komplette Tabelle für die Laufzeit der Anweisung.

Der richtige Weg sollte also sein:

  • herausfinden, warum die Tabelle so stark wächst
  • Autovacuum passend tunen
  • das ganze beobachten und ggf. nachjustieren

Danach, wenn das passt, einmalig die Tabelle zusammenstauchen und das Problem ist hoffentlich erledigt.

So wie es aktuell gelöst wurde, wird das Problem in naher Zukunft wohl wieder auftreten. Das war also nur eine kurzfristige Lösung ohne wirkliches Potential.

er hat anfangs geschrieben, dass er in der betroffenen tabelle sehr viele datensaetze geloescht hat … irgendwo hat er dann noch verraten, dass er auf der table schon ne weile rumgeritten ist … dabei ist wohl fsm-dingens uebergelaufen …

ich sage ja nicht, dass es falsch ist fsm-dingens zu erhöhen, ganz im gegentum

und soweit ich das sehe aendert fsm-dingens nichts an der lese-performance … es ermoeglicht doch nur, dass vacuum slots markieren kann die evtl wieder verwendet werden …

so sinnlos das select count(*) oft ist - hier wars ein deutlicher hinweis

Na ja, ich mag halt permanente Problemlösungen. Alles andere zieht nur wieder Arbeit in Zukunft nach sich - vor allem meistens in Zeiten, wo man das sowieso nicht brauchen kann.

Dazu gehört allerdings auch ein bischen Grundwissen, z. B. zur Konfiguration der Datenbank. Als DBA muss man so etwas voraussetzen.

Falsch.

Bei einem sequentiellen Scan müssen alle Blöcke gelesen werden. Doppelt so viele Blöcke dauern doppelt so lange.

hmm … stimmt … nur die ganz-leeren, die in der fsm landen werden nicht gelesen …

hast du irgendeinen erfahrungswert in % was man ansetzen sollte bei einer typischen OLTP db?

In der fsm steht nicht, ob ein Block komplett leer ist oder nicht.
Dort steht nur, ob es freien Platz in einem Block gibt, aber nicht, wieviel davon.


hast du irgendeinen erfahrungswert in % was man ansetzen sollte bei einer typischen OLTP db?

Erfahrungswert und Prozente für was?

ja stimmt …

anpassen von max_fsm_pages

In 8.4 wäre das doch überflüssig, oder?

Ja.

Wowereit!

Andreas

Cool - ich habe mich vorhin schon garnicht zu fragen getraut, warum man das ueberhaupt einstellen muss … eigentlich muss das nur mit der Db wachsen :wink:

schön, dass die macher das auch so sehen

Tja, schade aber auch, daß die nicht schon eher Dich gefragt haben, gell?

Hint: jedes Stück etwas komplexerer Software hat irgendwo Altlasten mit sich zu schleppen, wo man nach N Jahren sagen könnte: wie bekifft waren die denn, als die das so gemacht haben?

Und wenn ich als notorischer Windows-Nichtnutzer doch mal Windows nutzen muß, frage ich mich daß quasi im Millisekundenabstand.

Hint²: PG ist als Studienobjekt entstanden. Es war vorrangiges Ziel, Dinge wie Datensicherheit und Datenkonsistenz zu sichern, Performance galt einige bzw. lange Zeit als nicht vorrangiges Ziel.

Da gab es vor einigen Tagen auf [Hackers] erst ein Statement vonTom Lane, sinngemäß: laßt uns erst einmal definieren, was wir wollen, und das sicher implementieren. Dann kümmern wir uns um Performance. Es ging irgendwie um CTE bzw. um eine Erweiterung, ich finde es grad nicht.

Mittlerweile hat PG nicht nur den Ruf, Daten sicher zu verwahren, sondern auch noch dabei schnell zu sein. Das ist der positive Nebeneffekt, wenn man erst einmal versucht, sich um Konsistenz zu bemühen und dann das zu optimieren. (auch wenn das z.T. negative Kritik von wegen ‘PG ist lahm’ bringt). Ich kenne Leute im MySQL-Support (Hallo Susanne), die tagtäglich mit ‘verlorenenen’ Daten zu kämpfen haben …


Andreas