[Postgres] DELETE/TRUNCATE duurt te lang

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • ikke007
  • Registratie: Juni 2001
  • Laatst online: 18-09 14:10
Ik heb hier een nagenoeg lege database met 50 tabellen erin. Één tabel bevat 5 rijen. Deze tabel wordt door twee tabellen gerefereerd (foreign keys) waarbij de foreign keys als indexen zijn gemarkeerd. Overigens; deze twee tabellen zijn leeg. Er bestaan naar deze tabellen wel weer diverse references dmv verdere foreign keys.

Een DELETE FROM table_5_rijen (fictief) heeft na meer dan 5 minuten nog geen resultaat in PGAdmin. In pgsql zelfde situatie, na 5 minuten abort ik het maar omdat het naar mijn mening te lang duurt.
Een TRUNCATE TABLE table_5_rijen (fictief) heeft zelfde probleem.

Schema encoding: UTF-8
Postgres versie: (dmv 'SELECT version();') PostgreSQL 8.2.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.1.2

Mijn vraag aan jullie: herkennen jullie dit probleem of hebben jullie een idee waar dit aan kan liggen? Weten jullie een manier om het probleem te verhelpen? Of natuurlijk: iets wat mij in de goede richting kan zetten tot het oplossen ervan.
Google/Search@Tweakers bracht mij geen echte verlossing en in de mailing lists van postgres zelf staan wel diverse topics over performance maar zover ik zag niet allemaal met een oplossing of een relevant performance probleem.

Lets remove all security labels and let the problem of stupidity solve itself


Acties:
  • 0 Henk 'm!

  • justmental
  • Registratie: April 2000
  • Niet online

justmental

my heart, the beat

Heb je misschien nog een transactie open op een van de child tabellen?

Who is John Galt?


Acties:
  • 0 Henk 'm!

  • Kettrick
  • Registratie: Augustus 2000
  • Laatst online: 11:35

Kettrick

Rantmeister!

Dit kan je checken met

code:
1
SELECT * from pg_stat_activity;

Acties:
  • 0 Henk 'm!

  • Niemand_Anders
  • Registratie: Juli 2006
  • Laatst online: 09-07-2024

Niemand_Anders

Dat was ik niet..

Heb je al een vacuum geprobeert? Wat is de performance als je de references verwijderd? Gaat het dan sneller of maakt dat geen verschil. Refereert de tabel met 5 records naar de twee lege tabellen of verwijzen de twee lege tabellen naar de 5 record tabel?

In het geval van de eerste dan heb je een serieus probleem. Waarschijnlijk is de foreign key dan geplaatst nadat de records waren geinsert. PostgreSql (7.x, 8.x heb ik nog niet mee gewerkt) plaats gewoon de foreign key op de tabel. Helaas wordt dat niet met terug werkende kracht gecontroleerd.
In dat geval kan postgres de 5 records niet verwijderen, omdat de referentie naar 1 of beide tabellen niet gevonden kan worden.

If it isn't broken, fix it until it is..


Acties:
  • 0 Henk 'm!

  • ikke007
  • Registratie: Juni 2001
  • Laatst online: 18-09 14:10
De rijen zijn pas geinsert nadat de foreign keys op de tabellen gezet waren. De twee andere tabellen verwijzen naar de tabel met vijf rijen dmv de foreign keys.

Probleem 1; er stond een transaction 'vast' (waiting) welke ik heb laten killen door onze sysadmin. (kunnen zien door pg_stat_activity, bedankt RoeLz/justmental)
Probleem 2; Ik heb net VACUUM ANALYSE gedaan. Nu was het wel mogelijk om de tabel te wijzigen. (Bedankt Niemand_Anders)

Heb dan wel een truncate table ... cascade moeten doen omdat hij anders mekkert maar verder is het nu gelukt om die tabel leeg te gooien.

Damn, soms kan een probleem zo simpel op te lossen zijn.

Lets remove all security labels and let the problem of stupidity solve itself