Index löschen & neu erstellen, laufende Abfragen

Moin,

via CRON wird ein Index geDROPt und neu erstellt (concurrently), ist ein
partieller Index auf Daten der letzten N Tage.

Läuft seit Monaten problemlos, letzte Nacht hing allerdings das ganze.

Allgemeine Frage: ist das allgemein keine gute Idee, auf einem relativ
belasteten System einen Index wegzulöschen und mit gleichem Namen gleic=
h
neu zu erstellen? Es hing allerdings noch am DROP INDEX.

Sollte man da vorher erst mal Sperren setzen?



Andreas
--=20
Andreas Kretschmer
http://internet24.de

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: [pgsql-de-allgemein] Index löschen & neu erstellen, laufende Abfragen

On Oct 11, 2011, at 18:33 , Andreas Kretschmer wrote:

> Allgemeine Frage: ist das allgemein keine gute Idee, auf einem relativ
> belasteten System einen Index wegzulöschen und mit gleichem Namen gleich
> neu zu erstellen? Es hing allerdings noch am DROP INDEX.

DDL changes brauchen für die Laufzeit IIRC ein Access Exclusive Lock, d.h=
.. wenn da noch ne langlaufende TX am Table draufgegangen is muss sich das D=
ROP INDEX hintanstellen.

Und ich würd ausm Bauchgefühl heraus zuerst einen neuen Index anlegen u=
nd dann den alten droppen, aber das ist wohl Geschmacksache.

Unterm Strich sollts da wenig Unterschiede geben (Reihenfolge, Benamsung, e=
tc.)

> Sollte man da vorher erst mal Sperren setzen?

Geh, das lockt eh von selber, KISS!

lg,
Michael
--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Index löschen & neu erstellen, laufende Abfragen

On 11.10.2011 18:33, Andreas Kretschmer wrote:
> Moin,
>
> via CRON wird ein Index geDROPt und neu erstellt (concurrently), ist ei=
n
> partieller Index auf Daten der letzten N Tage.
>
> Läuft seit Monaten problemlos, letzte Nacht hing allerdings das ganze=
..

Hast Du mal geprüft wie bloody der Index war?

Meine Glaskugel sagt, dass könnte ein bloody Index gewesen sein.

> Allgemeine Frage: ist das allgemein keine gute Idee, auf einem relativ
> belasteten System einen Index wegzulöschen und mit gleichem Namen gle=
ich
> neu zu erstellen? Es hing allerdings noch am DROP INDEX.

Es ist allgemein keine gute Idee.

Statt Drop Index / Create Index - nimm das nächste Mal lieber Reindex.

http://www.postgresql.org/docs/current/static/sql-reindex.ht ml

Susanne

--=20
Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: In

Susanne Ebrecht wrote:
>> via CRON wird ein Index geDROPt und neu erstellt (concurrently), ist e=
in
>> partieller Index auf Daten der letzten N Tage.
>
> Statt Drop Index / Create Index - nimm das nächste Mal lieber Reindex=
..

Nette Idee, aber wenig hilfreich bei einem Index, dessen Definition sich
täglich ändert...


Andreas
--=20
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889=
°

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: [pgsql-de-allgemein] Index löschen & neu erstellen, laufende Abfragen

hallo ...

besser wird es sein, erst den neuen concurrently zu machen und in der folge=
transaktion den alten index zu killen.
das hält das "locking fenster" gering.
alternativ ist aber die frage, ob die lösung für dein problem nicht ehe=
r im bereich constraint exclusion zu finden ist.

liebe grüße,

hans


On Oct 11, 2011, at 6:33 PM, Andreas Kretschmer wrote:

> Moin,
>=20
> via CRON wird ein Index geDROPt und neu erstellt (concurrently), ist ein
> partieller Index auf Daten der letzten N Tage.
>=20
> Läuft seit Monaten problemlos, letzte Nacht hing allerdings das ganze.
>=20
> Allgemeine Frage: ist das allgemein keine gute Idee, auf einem relativ
> belasteten System einen Index wegzulöschen und mit gleichem Namen gleich
> neu zu erstellen? Es hing allerdings noch am DROP INDEX.
>=20
> Sollte man da vorher erst mal Sperren setzen?
>=20
>=20
>=20
> Andreas
> --=20
> Andreas Kretschmer
> http://internet24.de
>=20
> --=20
> Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-de-allgemein
>=20

--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Re

PostgreSQL - Hans-Jürgen Schönig wrote:

> hallo ...
>=20
> besser wird es sein, erst den neuen concurrently zu machen und in der f=
olgetransaktion den alten index zu killen.
> das hält das "locking fenster" gering.

Okay, war auch schon meine Idee.


> alternativ ist aber die frage, ob die lösung für dein problem nicht=
eher im bereich constraint exclusion zu finden ist.

Das hatte ich dem Kunden schon vorgeschlagen, aber wie das halt so ist,
er kam von $anderer_provider und der Umzug erfolgte in meinem Urlaub und
er selber hatte dazu nicht das Wissen ...

Und nun ist eine Downtime faktisch nicht machbar, da ist echt rund um
die Uhr Traffic.

Letztendlich kann mir/uns das auch egal sein, wir sind ja 'nur' der
Provider. Und $Kunde ist eh recht zufrieden, weil, bei anderem Provider
muß es wohl pro Woche immer einige Stunden Downtime gegeben haben...

Mal schauen, so als langfristige Option wird da ganz sicher
Partitionierung kommen.


Andreas
--=20
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889=
°

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein