[postgres] UPDATE verplaats record

[Verwijderd]

In een tabel heb ik 3 velden: ID (SERIAL), TITEL (VARCHAR), INHOUD (TEXT). Wanneer ik een record met bv. het veld TITEL wil UPDATE-en, dan wordt de record verplaatst naar het einde van de tabel, terwijl de ID hetzelfde blijft. Bijvoorbeeld ID: 1,2,3,4,5. Vervolgens na het UPDATE-en van ID=1 krijg ik ID: 2,3,4,5,1.

Bij MySQL ben ik gewend dat de records op dezelfde positie blijven staan in de tabel. Is dit bij Postgres niet zo?

[whoami]

Is dat een probleem dan?

De volgorde waarin het DBMS de records opslaat zou jou toch geen zorgen mogen baren? Als je de records in een bepaalde volgorde wilt, dan ga je ze toch ophalen dmv een query waarmee je je records ordered? (ORDER BY).

[Verwijderd]

Kennelijk niet. De positie van een record in een tabel zal dan ook niet gegarandeerd worden door de database, en zou ook geen betekenis moeten hebben op de werking van jou software. Als je een bepaalde volgorde wil afdwingen bij het uitlezen van je data zal je dat moeten doen met een ORDER BY in je SELECT statement.

/me does his 'Spuit 11 shuffle' once again and exits center stage this time around

[ Voor 13% gewijzigd door Verwijderd op 04-06-2003 16:36 ]

[Verwijderd]

Opzich is het geen probleem idd, want nu gebruik ik ook ORDER BY. Ik vroeg me alleen af wat het nut is om de record achterin de tabel te plaatsen, terwijl MySQL dit niet doet. Dus het klopt wel dat Postgres de ge-updated record altijd achterin de tabel plaatst?

[Verwijderd]

Misschien klinkt dit bot, maar ik vraag me af waarom je dit wil weten? Als dit puur uit technische interesse is kan je de sources van beide databases kijken hoe een UPDATE fysiek wordt uitgevoerd. Als je slechts eindgebruiker ben is deze vraag, zoals eerder gezegd, niet relevant.

Als ik een gok maak verwacht ik dat het heeft te maken met het feit dat PostgreSQL wel transacties ondersteunt waar MySQL dat niet doet. In MySQL wordt mogelijk het bestaande, fysieke record gewoon aangepast, waar in PostgreSQL wellicht een kopie wordt gemaakt met de nieuwe waarden, waarna met een COMMIT het nieuwe record 'valid' wordt gemaakt en het oude 'invalid', of met een ROLLBACK het oude record 'valid' blijft en het nieuwe 'invalid'.

Dit is echter niet gebaseerd op werkelijke kennis van de interne werking van de DBMSen, maar mijn algemene kennis van DB systemen. Bovendien zal de echte werking complexer zijn dan dit, maar dat mag je uit de source een een boek over database fundamentals halen.

[ACM]

Verwijderd schreef op 04 June 2003 @ 16:43:
Ik vroeg me alleen af wat het nut is om de record achterin de tabel te plaatsen, terwijl MySQL dit niet doet.

MySQL kiest hier een ordening, zelfs als je geen tijd wilt verspillen aan ordening zal mysql dat alsnog doen dus...
Meestal zal die ordening de eerst beschikbare index zijn, zoals de primary key van een tabel.

Als je echter ordent op een veld en dan verwacht dat mysql de rest van de data ook wel op dezelfde manier als zonder ordening zal ordenen kom je bedrogen uit, want dan doet mysql dat ineens niet meer...

Dus het klopt wel dat Postgres de ge-updated record altijd achterin de tabel plaatst?

Postgresql verplaatst het record niet, postgresql maakt een kopie van het record en plaatst dat op een beschikbare plaats. Vaak zal dat inderdaad achteraan zijn.

Let erop dat het oude record niet zomaar verwijderd wordt, aangezien er nog transacties mee bezig zouden kunnen zijn.

Dit is de reden dat je moet vacuum-en, eens in de zoveel tijd en is zowel een sterkte van postgres als een zwakte
(zoek eens op MVCC (multi version concurrency control) als je er meer over wilt weten)

[hobbit_be]

heeft postgre nog steeds een Vacuum nodig of kan ie dat bij zijn eentje? Een jaartje geleden ofzo was deze nog handmatig vereist wat postgre direct uit onze opties deed verdwijnen.

[ACM]

dat kan je wel automatiseren. Ik zie niet in waarom dat perse postgres uit je lijst van opties moet doen verwijderen. Maar ja dat is nog steeds niet vanuit postgres zelf geautomatiseerd, hoewel men er wel mee bezig zou zijn.

[xoror]

in 7.4 zit in contrib dir pg_autovacuum. een deamon die automatisch vacuum doet.
Maar ik geloof dat je daarvoor db statistics moet aanzetten.

het is nog steeds niet ideaal. Ze waren het wel bezig om het in de backends te proppen, maar ik betwijfel of we die feature zien in 7.4

anyway, vacuum is niet z'n probleem, gewoon cronjob maken. vacuum analyze locked de tables niet dus je heb er 'geen last' van.