Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

[Postgres] DELETE/TRUNCATE duurt te lang

Pagina: 1
Acties:

Onderwerpen


  • ikke007
  • Registratie: juni 2001
  • Laatst online: 07-06-2019
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


  • 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?


  • Kettrick
  • Registratie: augustus 2000
  • Laatst online: 22:53

Kettrick

Rantmeister!

Dit kan je checken met
code:
1
SELECT * from pg_stat_activity;


  • Niemand_Anders
  • Registratie: juli 2006
  • Laatst online: 18-12-2019

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


  • ikke007
  • Registratie: juni 2001
  • Laatst online: 07-06-2019
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



Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True