[PostgreSQL] Indexes

[B-Man]

N.a.v. deze post van ACM open ik even een nieuw topic.

Ik las namelijk zojuist (opnieuw) in de PostgreSQL manual (helemaal onderaan), dat:

...
Note that a query or data manipulation command can use at most one index per table.

ACM: hoe zit het nu? Ik loop nu al wel eens tegen de beperking van MySQL aan dat er maar een index per tabel (per query) gebruikt kan worden. Dit betekent dat ik soms voor grote tabellen meerdere multi-column en tevens losse indices moet aanmaken om een beetje snelle SELECTs te hebben. Als postgres in staat is om meerdere losse indices te gebruiken scheelt me dit een berg aan opslagruimte, en performance (snellere INSERTs en UPDATEs aangezien er minder indices bijgwerkt worden).

Zou je in dit topic toelichting willen geven?

[jochemd]

ACM verwijst expliciet naar versie 8.1 Beta van PostgreSQL. Jij zoekt in de handleiding van 8.0.

PostgreSQL 8.0 kan slechts één index gebruiken per keer dat een table voorkomt in de FROM.


Je kan deels het gebruik van meerdere indexen op één scan simuleren in PostgreSQL door gebruik te maken van een GiST index die multidimensionaal is. Bijvoorbeeld bij geodata wordt daar gebruik van gemaakt, in plaats van afzonderlijke indexen op de X en Y as wordt er dan een index op X & Y tegelijk aangemaakt. Dat verschilt in zoverre van een gewone B-tree index op twee kolommen dat je in in B-tree index alleen random door de eerste kolom kan zoeken, terwijl je in een GiST index zowel random door de eerste als door de tweede kan zoeken.

PostgreSQL 8.1, momenteel in beta, kan wel meerdere indexen gebruiken voor één scan.

[ACM]

jochemd schreef op maandag 19 september 2005 @ 16:11:
PostgreSQL 8.0 kan slechts één index gebruiken per keer dat een table voorkomt in de FROM.

Ik wist anders met 7.3 al een situatie waarbij twee indexen bruikbaar waren, in een door mij gegeven constructie. Namelijk dat er twee aparte takken voor bijv OR mogelijk zijn.

Ik heb het nog even nagezocht en zie hier:
http://archives.postgresq...eral/2003-01/msg01555.php
Uit een van de execution plans kreeg ik (min of meer toevallig, ik was zelf ook blij verrast):

 Index Scan using f_topics_forum_status_deleted, f_topics_forum_lastmessage_deleted on f_topics (cost=0.00..241.87 rows=60 width=12)
Index Cond: (((forumid = 15) AND (statusid = 1) AND (deleted = false)) OR ((forumid = 15) AND (lastmessage > '2002-08-01 23:27:03'::timestamp without time zone) AND (deleted = false)))
Filter: (((statusid = 1) AND (deleted = false) AND (forumid = 15)) OR ((lastmessage > '2002-08-01 23:27:03'::timestamp without time zone) AND (deleted = false) AND (forumid = 15)))
(3 rows)

En daarbij gebruikte ie toch echt twee verschillende indexen voor één tabel. Je hebt echter gelijk als je bedoelt dat ie niet verschillende indexen kan combineren als er niet zo'n duidelijke scheiding in aan te brengen is.

Als er een tabel test(a, b, c, d) met op a, b, c en d aparte indexen is en je doet een query ala:
select * from test where a = X and b = Y and c = Z dan zal ie de (naar schatting) meest selectieve index gebruiken en verder niets kunnen, in versies tot 8.1.

[B-Man]

ACM: dank voor je uitleg, ik ga toch eens in wat meer detail naar postgresql kijken.
Een ding wat ik er nog in mis, maar wat er vermoedelijk nooit in gaat komen is wel de mogelijkheid tot cross-database queries die MySQL heeft.
Waar ik het voor nodig heb is een systeem waarin systeem-brede zaken in een algemene database staan, en er per klant/gebruiker (custom datamodel, beveiliging) een database is. Gezien de complexiteit van de klantdata was het daar niet wenselijk om alles in een database te stoppen.

[ACM]

In Postgres heb je de schema's, wat in principe net zo werkt als MySQL's databases. Namelijk aparte namespaces voor tabellen binnen een opslag-systeem. Dus dat je jouwschema.tabelnaam.kolom kunt gebruiken en ook niet per se standaard alle tabellen te zien krijgt als je inlogt.

Ik geloof dat er verder in 'contrib' ook wel packages zitten om echt cross-database te gaan, maar imho kan je beter eerst naar schema's kijken voor je gaat klooien met losse databases. Die zijn in MySQL inderdaad een stuk handiger samen te gebruiken, maar eigenlijk is het een beetje een vieze vorm van mixing van aparte databases en schema's door elkaar heen.

Voor de fysieke opslag is er, net als bij MySQL, geen reden het in losse databases op te slaan. Hoogut voor het rechtenbeheer, maar vziw kan je net zo makkelijk grants op schema's loslaten in Postgres als in MySQL op databases. Dat laatste heb ik echter nooit zelf bekeken.
Overigens kan je bij Postgres itt MySQL wel bepalen waar tables/indices, schema's of databases standaard terechtkomen (als je dus een aparte tablespace aanmaakt).

[ Voor 17% gewijzigd door ACM op 20-09-2005 21:45 ]

[B-Man]

ACM schreef op dinsdag 20 september 2005 @ 21:37:
In Postgres heb je de schema's, wat in principe net zo werkt als MySQL's databases. Namelijk aparte namespaces voor tabellen binnen een opslag-systeem. Dus dat je jouwschema.tabelnaam.kolom kunt gebruiken en ook niet per se standaard alle tabellen te zien krijgt als je inlogt.

Ik geloof dat er verder in 'contrib' ook wel packages zitten om echt cross-database te gaan, maar imho kan je beter eerst naar schema's kijken voor je gaat klooien met losse databases. Die zijn in MySQL inderdaad een stuk handiger samen te gebruiken, maar eigenlijk is het een beetje een vieze vorm van mixing van aparte databases en schema's door elkaar heen.

Voor de fysieke opslag is er, net als bij MySQL, geen reden het in losse databases op te slaan. Hoogut voor het rechtenbeheer, maar vziw kan je net zo makkelijk grants op schema's loslaten in Postgres als in MySQL op databases. Dat laatste heb ik echter nooit zelf bekeken.
Overigens kan je bij Postgres itt MySQL wel bepalen waar tables/indices, schema's of databases standaard terechtkomen (als je dus een aparte tablespace aanmaakt).

Bedankt! Ik heb eerder al een heleboel zaken bekeken/gelezen over Postgres, maar nog niet eerder in detail de schema functionaliteit bekeken. Dat ziet er een stuk netter uit als de oplossing die ik nu in MySQL hanteer!
Mijn DAL hoeft zo ook niet veel te veranderen zie ik, aangezien ik van de MySQL manier (SELECT * FROM dbnaam.tabelnaam) op de Postgres manier kan overstappen (SELECT * FROM schemanaam.tabelnaam).

Ik was al tijden aan het kijken naar een overstap op Postgres, omdat ik met steeds complexere data en concurrency begin te werken, en op dat vlak meer vertrouwen heb in Postgres. Dat is natuurlijk gevoelsmatig, maar als ik kijk naar zaken als views zou ik die ook goed kunnen toepassen, maar dan liever een uitgekristalliseerde implementatie, en niet de versie van MySQL die nog beta is.

ACM: bedankt voor je reacties, ik heb genoeg redenen om eens concreet een overstap naar Postgres te gaan bekijken. Heb je nog tips qua boeken/artikelen die interessant zijn qua beheer en performance tuning?

[Alarmnummer]

Ik heb zelf net Postgresql in een 2-tal projecten gebruikt, maar vond de tooling soms wel een beetje ondermaats. De win32 gui voor Postgres die crashte op sommige stukken steeds (dus die stukken maar niet meer in) en verder waren sommige dingen niet mogelijk omdat de knoppen gedisabled waren (en dat niet horen te zijn), bv backups terug zetten.

Als ik met mijn praktische pet ernaar kijk is mijn beeld op dit moment niet echt super positief. En bij ons wordt de vraag ook gesteld of we dit product in de toekomst moeten blijven gebruiken.

[edit]
Ik werk gewoonlijk met MS Sql.. en alhoewel de tools soms wat spartaans aanvoelen, werkt het goed. De enigste reden dat ik voor Postgresql kies is de kosten.

[ Voor 16% gewijzigd door Alarmnummer op 20-09-2005 22:48 ]

[ACM]

B-Man schreef op dinsdag 20 september 2005 @ 22:20:
Ik was al tijden aan het kijken naar een overstap op Postgres, omdat ik met steeds complexere data en concurrency begin te werken, en op dat vlak meer vertrouwen heb in Postgres.

Bij mij is het niet gevoelsmatig, Postgres kan gewoon beter met complexe queries overweg. Ik heb met nog relatief simpele queries tijdsverschillen met factoren van 4-10 gezien in het voordeel van Postgres.

ACM: bedankt voor je reacties, ik heb genoeg redenen om eens concreet een overstap naar Postgres te gaan bekijken. Heb je nog tips qua boeken/artikelen die interessant zijn qua beheer en performance tuning?

Sowieso is er een hele serie postgresql-mailinglists. Verder moet je bij Postgres je database actief (laten) opschonen wat oude "tuples" betreft (wat ik nog wel een beetje een gemis vind) en de data laten analyzeren als de inhoud van een tabel verandert.
Meestal doe ik na een batch-insert/update dan ook gewoon "vacuum full analyze" als extra statement erbij, de autovacuum daemon is verder nuttig als je data continu bijgewerkt wordt.

Zonder goed geanalyzeerde data kan Postgres geen fatsoenlijke plannen maken voor de query-executie en krijg je dus inefficiente plannen. Met het explain-commando kan je vrij goed zien (soms wat lastig te interpreteren) hoe een query uitgevoerd wordt en op de psql-performance lijst is men vaak heel erg bereid je dan te helpen met specifieke queries.

Kijk dan hier nog even naar de performance checklist, dan heb je de basis-tuning wel gehad. Op die powerpostgresql-website staat verder nog de annotated configuratie, die wat uitgebreidere tips geeft over bepaalde parameters dan in de configuratiefile zelf al staat.

[ACM]

Alarmnummer schreef op dinsdag 20 september 2005 @ 22:34:
Ik heb zelf net Postgresql in een 2-tal projecten gebruikt, maar vond de tooling soms wel een beetje ondermaats. De win32 gui voor Postgres die crashte op sommige stukken steeds (dus die stukken maar niet meer in) en verder waren sommige dingen niet mogelijk omdat de knoppen gedisabled waren (en dat niet horen te zijn), bv backups terug zetten.

Mja, Postgres in win32 is idd pas sinds kort (v8) een beetje ondersteund, maar over het algemeen vind ik de beschikbare tools niet minder bruikbaar dan die voor MySQL. De psql-cli is iig krachtiger en bruikbaarder dan de mysql-cli en daarom gebruik ik die vrij veel.

Als ik met mijn praktische pet ernaar kijk is mijn beeld op dit moment niet echt super positief. En bij ons wordt de vraag ook gesteld of we dit product in de toekomst moeten blijven gebruiken.

Vergeleken met MySQL is tegenwoordig de praktische bruikbaarheid ongeveer vergelijkbaar, misschien dat MySQL op win32 bruikbaarder is maar dat heb ik nooit bekeken.

Ik werk gewoonlijk met MS Sql.. en alhoewel de tools soms wat spartaans aanvoelen, werkt het goed. De enigste reden dat ik voor Postgresql kies is de kosten.

Met MS Sql heb ik minder goede ervaringen dan met postgres, maar das wel van lang geleden en ook gebaseerd op relatief weinig tijd
Maar ik kan nog wel meer redenen bedenken hoor. Lagere footprint (zeker vergeleken met oracle), vergelijkbare en in sommige gevallen zelfs betere performance (hangt dus van je app af) - uiteraard soms ook slechter, op sommige punten uitgebreider of handiger uit te breiden (hoewel mijn MS SQL-ervaring dus niet echt erg groot is).

Maar het hangt vooral van je app af welke beter is en dan zijn er ook nog de kosten Als de kosten je minder uitmaken en je gewoon een goed systeem met fatsoenlijke tools wilt, dan zijn er overigens ook commerciele versies van Postgres waarbij meestal vooral de beheerstools flink aangepakt zijn.

[Alarmnummer]

ACM schreef op woensdag 21 september 2005 @ 08:00:
Mja, Postgres in win32 is idd pas sinds kort (v8) een beetje ondersteund, maar over het algemeen vind ik de beschikbare tools niet minder bruikbaar dan die voor MySQL. De psql-cli is iig krachtiger en bruikbaarder dan de mysql-cli en daarom gebruik ik die vrij veel.

Ik heb een aantal MySql tools gezien en daarbij waren simpele handelingen zoals tabellen copieeren ook echt simpel. Met Postgresql was dit een stuk complexer (lees erg veel werk).

Maar het hangt vooral van je app af welke beter is en dan zijn er ook nog de kosten Als de kosten je minder uitmaken en je gewoon een goed systeem met fatsoenlijke tools wilt, dan zijn er overigens ook commerciele versies van Postgres waarbij meestal vooral de beheerstools flink aangepakt zijn.

Hmm tja.

Over de db zelf heb ik eigelijk weinig aan te merken. En de techneut in me heeft ook geen problemen met Postgresql. Maar als ik door wil werken, dan wil ik tooling dat gewoon out of the box goed werkt en ik wil niet overal wat spul bij elkaar verzamelen. Op het moment dat dat een vaste lijn vormt binnen een product, dan weet ik dat het dat het een continue bron van problemen kan worden (en problemen = tijd). Ik zal eens kijken naar commercieele tools, want ik geloof dat je voor een Ms Sql licentie ook een 200/300 euro per maand kwijt bent.

[JaQ]

ACM schreef op woensdag 21 september 2005 @ 07:53:
[...]
Sowieso is er een hele serie postgresql-mailinglists. Verder moet je bij Postgres je database actief (laten) opschonen wat oude "tuples" betreft (wat ik nog wel een beetje een gemis vind) en de data laten analyzeren als de inhoud van een tabel verandert.
Meestal doe ik na een batch-insert/update dan ook gewoon "vacuum full analyze" als extra statement erbij, de autovacuum daemon is verder nuttig als je data continu bijgewerkt wordt.

Zonder goed geanalyzeerde data kan Postgres geen fatsoenlijke plannen maken voor de query-executie en krijg je dus inefficiente plannen. Met het explain-commando kan je vrij goed zien (soms wat lastig te interpreteren) hoe een query uitgevoerd wordt en op de psql-performance lijst is men vaak heel erg bereid je dan te helpen met specifieke queries.

Vertel je hier dat Postgres alleen cost-based een executieplan kan maken? Kan je geen rule-based executie plan afdwingen als je een query maakt? (eventueel met index-hints oid)

Ach.. en als je toch al helemaal ondervraagd wordt.. Hoe gaat postgres om met tabellen zonder index. In sommige gevallen is dit namelijk sneller in Oracle. (denk aan kleine code tabellen die sneller in een keer in geheugen geladen kunnen worden, dan dat eerst de index geladen en daarna nog eens de relevante rij geladen kan worden. e.e.a. is uiteraard afhankelijk van je db_block_size)

[jochemd]

ACM schreef op maandag 19 september 2005 @ 18:30:
[...]

Ik wist anders met 7.3 al een situatie waarbij twee indexen bruikbaar waren, in een door mij gegeven constructie. Namelijk dat er twee aparte takken voor bijv OR mogelijk zijn.

Ik heb het nog even nagezocht en zie hier:
http://archives.postgresq...eral/2003-01/msg01555.php
Uit een van de execution plans kreeg ik (min of meer toevallig, ik was zelf ook blij verrast):

 Index Scan using f_topics_forum_status_deleted, f_topics_forum_lastmessage_deleted on f_topics (cost=0.00..241.87 rows=60 width=12)
Index Cond: (((forumid = 15) AND (statusid = 1) AND (deleted = false)) OR ((forumid = 15) AND (lastmessage > '2002-08-01 23:27:03'::timestamp without time zone) AND (deleted = false)))
Filter: (((statusid = 1) AND (deleted = false) AND (forumid = 15)) OR ((lastmessage > '2002-08-01 23:27:03'::timestamp without time zone) AND (deleted = false) AND (forumid = 15)))
(3 rows)

Het lijkt er inderdaad op dat 7.3 het al kon. Hoe precies snap ik niet, want tenzij de records van f_topics_forum_status_deleted mutually exclusive zijn met die van f_topics_forum_lastmessage_deleted (partiele indexen?) moet daar ergens nog een stap bij komen om dubbele TIDs er uit te filteren. En die stap zie ik niet terug.

Overigens is jouw voorbeeld ook niet helemaal gelijk aan wat je in de andere thread beweert.

code:

Predicaat:
WHERE (a.n = n AND a.m = m AND a.o = o)
OR (a.n = n AND a.m = m AND a.p = p)

Herschreven predicaat:
WHERE a.n = n AND a.m = m AND (a.o = o OR a.p = p)

Indexen in je verhaal:
n, m, o
n, m, p

Indexen in je post naar pgsql-general:
n, o, m
n, p, m

Het is niet geheel onverwachts dat met de eerste set indexen daar een ander plan uit komt dan met de tweede set indexen.
_{Je dacht toch niet dat je zo makkelijk gelijk kreeg hè?}

[jochemd]

Alarmnummer schreef op dinsdag 20 september 2005 @ 22:34:
Ik heb zelf net Postgresql in een 2-tal projecten gebruikt, maar vond de tooling soms wel een beetje ondermaats. De win32 gui voor Postgres die crashte op sommige stukken steeds (dus die stukken maar niet meer in) en verder waren sommige dingen niet mogelijk omdat de knoppen gedisabled waren (en dat niet horen te zijn), bv backups terug zetten.

Het is een beetje lastig om te beoordelen of het niet gewoon PEBKAC was aangezien je naam in z'n geheel niet te vinden is op enige PostgreSQL mailinglist of bugreport. Je zou op z'n minst kunnen zeggen welke win32 GUI je hebt gebruikt.

Als ik met mijn praktische pet ernaar kijk is mijn beeld op dit moment niet echt super positief. En bij ons wordt de vraag ook gesteld of we dit product in de toekomst moeten blijven gebruiken.

Mijn practische pet zegt dat mijn eigen score ongeveer 20% bug en 80% PEBKAC is, waarbij ik nooit langer dan 36 uur op een fix heb hoeven wachten.

De enigste reden dat ik voor Postgresql kies is de kosten.

Kosten is bij mij juist bijna nooit een overweging om PostgreSQL aan te bevelen. Ik adviseer mensen ook altijd om een support contract voor PostgreSQL af te sluiten.
De reden om PostgreSQL te adviseren is de combinatie van Open Source en goede ondersteuning van standaarden zoals SQL. In bepaalde sectoren worden er soms de jure onverwachte eisen gesteld aan software. Zo is het soms zo dat als je bepaalde soorten persoonsgegevens verwerkt je toegang moet hebben tot de sourcecode van de software waarmee je die verwerkt. Het is gewoon te veel rompslomp om dat soort dingen met een closed source vendor te gaan regelen.

[jochemd]

DrFrankenstoner schreef op woensdag 21 september 2005 @ 09:45:

Vertel je hier dat Postgres alleen cost-based een executieplan kan maken? Kan je geen rule-based executie plan afdwingen als je een query maakt? (eventueel met index-hints oid)

Of en welke index je gebruikt is in PostgreSQL per definitie cost-based: rule-based is namelijk (binnen zekere grenzen) geimplementeerd als het kunstmatig verhogen van de cost
De volgorde van joins is standaard cost-based. Voor queries met weinig tabellen op basis van exhaustive search, voor queries met veel tabellen met een genetisch algorithme. Als je wil kan je door het zetten van een parameter ervoor kiezen om het keyword JOIN ook de volgorde van de join vast te laten leggen zodat in A JOIN B altijd voor A als driving tabel gekozen wordt.

Ach.. en als je toch al helemaal ondervraagd wordt.. Hoe gaat postgres om met tabellen zonder index.

Die krijgen altijd een table scan in plaats van een index scan

[Alarmnummer]

jochemd schreef op woensdag 21 september 2005 @ 10:36:
[...]
Het is een beetje lastig om te beoordelen of het niet gewoon PEBKAC was aangezien je naam in z'n geheel niet te vinden is op enige PostgreSQL mailinglist of bugreport.

PEBKAC? En verder stuur ik geen bugreports of ga naar mailinglisten als ik niet lang met een product bezig ben.

Je zou op z'n minst kunnen zeggen welke win32 GUI je hebt gebruikt.

De gui die standaard bij de win32 versie (8.1 geloof ik) wordt meegeleverd.

Kosten is bij mij juist bijna nooit een overweging om PostgreSQL aan te bevelen. Ik adviseer mensen ook altijd om een support contract voor PostgreSQL af te sluiten.

Bij ons is het de enigste reden. We werken gewoonlijk met Ms SQL en dat doen we naar alle tevredenheid. Tooling is uitgebreid en werkt goed. En verder is er enorm veel literatuur over te vinden.

Zo is het soms zo dat als je bepaalde soorten persoonsgegevens verwerkt je toegang moet hebben tot de sourcecode van de software waarmee je die verwerkt.

Dat is voor ons een non argument. We hebben niet de ilusie dat we iets kunnen (en gaan) aanpassen van PosrgresSQL.

Een belangrijke opmerking:
Ik vind een database een handige tool om data op te kunnen slaan, maar verder interesseren ze me eigelijk niet. Vanuit java (daar werk ik meestal mee) is het totaal niet interessant welke db je gebruikt. Gezien mijn interesse voor db`s en mijn chronisch gebrek aan tijd, heb ik niet de behoefte om veel tijd te spenderen aan alle problemen van een db. Op het moment dat een specifieke db zorgt voor brood op de plank, dan wil (en ga) ik daar ook echt tijd aan besteden. Maar op het moment dat een db (of zijn tooling) te veel kuren vertoont, dan heb ik zoiets van: geen hand vol maar een land vol. Ik wil niet zeggen dat PostgresSQL een slecht product is en dat we het in de toekomst niet weer gaan gebruiken, ik zeg alleen dat we teleurgesteld zijn in de tooling en onze ogen openhouden.

[ Voor 12% gewijzigd door Alarmnummer op 21-09-2005 11:00 ]

[ACM]

DrFrankenstoner schreef op woensdag 21 september 2005 @ 09:45:
Vertel je hier dat Postgres alleen cost-based een executieplan kan maken? Kan je geen rule-based executie plan afdwingen als je een query maakt? (eventueel met index-hints oid)

Nee, hints zijn vziw niet mogelijk. Wel kan je nog heel rudimentair de bepaalde typen van scanning uitzetten (je kan de sequential scan verbieden en na de query weer aanzetten).
Ik weet eigenlijk niet of de hints er ooit inkomen, het is wel gevraagd als featurerequests maar in die gevallen dat ik er over las was het antwoord dat men liever werk stak in het verbeteren van de query-planner dan een dergelijk complex systeem te ontwikkelen en voor elke wijziging aan de planner bij te houden.

Ach.. en als je toch al helemaal ondervraagd wordt.. Hoe gaat postgres om met tabellen zonder index. In sommige gevallen is dit namelijk sneller in Oracle. (denk aan kleine code tabellen die sneller in een keer in geheugen geladen kunnen worden, dan dat eerst de index geladen en daarna nog eens de relevante rij geladen kan worden. e.e.a. is uiteraard afhankelijk van je db_block_size)

Postgres doet het omgekeerd. Zelfs als jij een index op een kleine tabel hebt zal ie die negeren omdat het sneller is domweg de hele tabel in te laden, dat is dan weer een voordeel van een cost-based planner. Overigens doet ie hetzelfde voor grote tabellen als blijkt dat ie een te groot deel van de table-pages in moet laden, waardoor het efficienter is om gewoon sequentieel de boel in te lezen dan random dat grote deel van pages op te snorren.

jochemd schreef op woensdag 21 september 2005 @ 10:20:
Het lijkt er inderdaad op dat 7.3 het al kon. Hoe precies snap ik niet, want tenzij de records van f_topics_forum_status_deleted mutually exclusive zijn met die van f_topics_forum_lastmessage_deleted (partiele indexen?) moet daar ergens nog een stap bij komen om dubbele TIDs er uit te filteren. En die stap zie ik niet terug.

Het waren beide geen partiele indexen vziw, maar het was allemaal zo lang geleden dat de details er allemaal een beetje bij ingeschoten zijn

_{Je dacht toch niet dat je zo makkelijk gelijk kreeg hè?}

Zie de datum van die posting

edit:

En jochemd is deels weer wat vollediger

[jochemd]

Alarmnummer schreef op woensdag 21 september 2005 @ 10:52:

PEBKAC? En verder stuur ik geen bugreports of ga naar mailinglisten als ik niet lang met een product bezig ben.

Problem Exists Between Keyboard And Chair

Het niet kunnen backuppen of restoren vanuit een GUI is bijvoorbeeld meestal het gevolg van het niet installeren van alle client utilities omdat de GUI gebruik maakt van de van pg_dump en pg_restore utilities.

Dat is voor ons een non argument. We hebben niet de ilusie dat we iets kunnen (en gaan) aanpassen van PosrgresSQL.

Die illusie heb ik ook niet. Maar er staat niet voor niets de jure bij: als het een wettelijke verplichting is dan doe je het gewoon.

[Alarmnummer]

jochemd schreef op woensdag 21 september 2005 @ 11:09:
[...]
Problem Exists Between Keyboard And Chair

Aha ok. Maar het plotseling verdwijnen van de gui (een crash) valt bij mij onder IINMF (it is not my fault).

Het niet kunnen backuppen of restoren vanuit een GUI is bijvoorbeeld meestal het gevolg van het niet installeren van alle client utilities omdat de GUI gebruik maakt van de van pg_dump en pg_restore utilities.

Het was mij en andere mensen niet meteen duidelijk. Alles wat niet binnen 5 minuten duidelijk is fout

Je moet niet vergeten dat ik met veel software te maken heb en op het moment dat simpele dingen niet snel werken, dan ga ik naar een alternatief stuk software toe. Op het moment dat databases je brood zijn zul je ook met een hele andere pet ernaar kijken, maar voor mij is het een stuk gereedschap om data in op te slaan.

[ Voor 6% gewijzigd door Alarmnummer op 21-09-2005 11:18 ]

[D4Skunk]

Jullie spreken IMHO over twee verschillende zaken : de database voor het opslaan van gegevens, en de database als ontwikkelomgeving.

• Iemand die slechts sporadisch db-management doet (developper bv) heeft echt wel nood een een goede gui.
• Iemand die echt administratie doet, gebruikt meestal niet de gui, maar de command line.

Zo merk ik bv dat ik zelf voor ontwikkeling mijn sql-tabellen etc in MSSQL enterprise manager bewerk, maar dat ik het beheer van tig Oracle-db's bij onze nationale tv volledig vanuit de cli-tools ga beheren.

Wat overigens het verschil tussen postgres- en Mysql betreft : IMHO gaat dit verschil langzaam maar zeker wegvloeien.
Wanneer ik kijk naar de manier waarop beide databases opgebouwd zijn, kan je niet om het feit heen dat postgres meer oracle benadert, en mysql eigenlijk een soort veredeled indexed filesystem is was, dat je met SQL kan benaderen. Voor de meeste applicaties is mysql echter toereikend, en -niet onbelangrijk -, het heeft een zeer grote userbase

[jochemd]

D4Skunk schreef op woensdag 21 september 2005 @ 11:44:
Wat overigens het verschil tussen postgres- en Mysql betreft : IMHO gaat dit verschil langzaam maar zeker wegvloeien.

Qua capaciteiten wel, maar qua development cycle merk ik er nog niets van. Ik zie een heel duidelijk verschil tussen de uiterst conservatieve benadering van de PGDG en de ad-hoc ontwikkelingen bij MySQL.

Laat ik als voorbeeld eens de recente aanpassingen aan joins nemen die MySQL heeft doorgevoerd (WL#2486). Effectief komen die er op neer dat iedereen die joins met NATURAL of USING gebruikt bij benadering 100% kans heeft dat hij die moet herschrijven. MySQL weet al sinds februari 2004 van dit probleem en geeft sinds september 2004 in de bugtracker aan dat er een change aankomt die dit gedrag zal wijzigen. Wordt daar in de release notes of ergens in de documentatie van 4.0.x voor gewaarschuwd? 4.1.x? Nee hoor, MySQL voert uiteindelijk de wijziging door in versie 5.0.12 (en het is een verplichte wijziging, geen configuratie optie). Maar 5.0.12 is een beta versie, en volgens de eigen richtlijnen voor releases worden dergelijke wijzigingen die zeker applicatiewijzigingen veroorzaken alleen tijdens een alfa gedaan.
Dat is gewoon niet professioneel.

Vergelijk dat aan de andere kant eens met PostgreSQL. Daar hebben ze in 7.2 aangekondigd dat het inserten van een lege string in een INT in de toekomst uitgefaseerd zou worden. Tegelijkertijd hebben ze een optie toegevoegd om dat gedrag te sturen zodat er vast getest kan worden. In 7.3 is de default voor die optie omgezet, maar door de default aan te passen kan je nog steeds het oude gedrag krijgen. En pas in 8.0 kan je het oude gedrag niet meer krijgen.

Wanneer ik kijk naar de manier waarop beide databases opgebouwd zijn, kan je niet om het feit heen dat postgres meer oracle benadert, en mysql eigenlijk een soort veredeled indexed filesystem is was, dat je met SQL kan benaderen.

Dat is een beetje inherent aan het woord ISAM.

Voor de meeste applicaties is mysql echter toereikend, en -niet onbelangrijk -, het heeft een zeer grote userbase

Op een gegeven moment voegt een grotere userbase niets meer toe omdat het toch users zijn die puur en alleen consumenten zijn, mailinglists verstoppen, met oogkleppen op /. gaan trollen en niets bijdragen. Ik heb liever dat een paar grote partijen die iets bijdragen tot de userbase behoren dan een berg consumenten.