Bookmarks

Yahoo Gmail Google Facebook Delicious Twitter Reddit Stumpleupon Myspace Digg

Search queries

/proc/kallsyms format, sqldatasource dal, wwwxxxenden, convert raid5 to raid 10 mdadm, apache force chunked, nrao wwwxxx, xxxxxdup, procmail change subject header, wwwXxx not20, Wwwxxx.doks sas

Links

XODOX
Impressum

#1: Index löschen & neu erstellen, laufende Abfragen

Posted on 2011-10-11 18:33:42 by Andreas Kretschmer

Moin,

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

L=E4uft 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=F6schen 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

Report this message

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

Posted on 2011-10-11 19:02:10 by Michael Renner

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=F6schen und mit gleichem Namen gleich
> neu zu erstellen? Es hing allerdings noch am DROP INDEX.

DDL changes brauchen f=FCr 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=FCrd ausm Bauchgef=FChl 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

Report this message

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

Posted on 2011-10-12 10:12:09 by Susanne Ebrecht

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=E4uft seit Monaten problemlos, letzte Nacht hing allerdings das ganze=
..

Hast Du mal gepr=FCft wie bloody der Index war?

Meine Glaskugel sagt, dass k=F6nnte ein bloody Index gewesen sein.

> Allgemeine Frage: ist das allgemein keine gute Idee, auf einem relativ
> belasteten System einen Index wegzul=F6schen 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=E4chste 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

Report this message

#4: Re: In

Posted on 2011-10-12 10:14:31 by Andreas Kretschmer

Susanne Ebrecht <susanne@2ndQuadrant.com> 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=E4chste Mal lieber Reindex=
..

Nette Idee, aber wenig hilfreich bei einem Index, dessen Definition sich
t=E4glich =E4ndert...


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=B0, E 13.56889=
=B0

--=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

Report this message

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

Posted on 2011-10-12 11:32:56 by Hans-Juergen Schoenig

hallo ...

besser wird es sein, erst den neuen concurrently zu machen und in der folge=
transaktion den alten index zu killen.
das h=E4lt das "locking fenster" gering.
alternativ ist aber die frage, ob die l=F6sung f=FCr 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=E4uft 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=F6schen 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=F6nig & Sch=F6nig GmbH
Gr=F6hrm=FChlgasse 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

Report this message

#6: Re: Re

Posted on 2011-10-12 12:47:02 by Andreas Kretschmer

PostgreSQL - Hans-J=FCrgen Sch=F6nig <postgres@cybertec.at> 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=E4lt das "locking fenster" gering.

Okay, war auch schon meine Idee.


> alternativ ist aber die frage, ob die l=F6sung f=FCr 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=DF 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=B0, E 13.56889=
=B0

--=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

Report this message