Software-update: PostgreSQL 12

PostgreSQL logo (75 pix) Versie 12 van PostgreSQL is uitgekomen. Dit populaire 'opensource relational database management system' draait op een groot aantal besturingssystemen en is daardoor uitstekend inzetbaar in diverse omgevingen. Het is een afgeleide van Ingres, nadat de hoofdontwikkelaar daarvan voor zichzelf is begonnen en deze database van opensource closedsource werd. Uitgebreide informatie over de veranderingen in versie 12 kan het deze pagina worden gevonden. De complete changelog staat hier, dit zijn in het kort de belangrijkste verbeteringen:

Major enhancements in PostgreSQL 12 include:
  • General performance improvements, including:
    • Optimizations to space utilization and read/write performance for B-tree indexes
    • Partitioning performance enhancements, including improved query performance on tables with thousands of partitions, improved insertion performance with INSERT and COPY, and the ability to execute ALTER TABLE ATTACH PARTITION without blocking queries
    • Automatic (but overridable) inlining of common table expressions (CTEs)
    • Reduction of WAL overhead for creation of GiST, GIN, and SP-GiST indexes
    • Support for covering GiST indexes, via the INCLUDE clause
    • Multi-column most-common-value (MCV) statistics can be defined via CREATE STATISTICS, to support better plans for queries that test several non-uniformly-distributed columns
  • Enhancements to administrative functionality, including:
  • Support for the SQL/JSON path language
  • Stored generated columns
  • Nondeterministic ICU collations, enabling case-insensitive and accent-insensitive grouping and ordering
  • New authentication features, including:
    • Encryption of TCP/IP connections when using GSSAPI authentication
    • Discovery of LDAP servers using DNS SRV records
    • Multi-factor authentication, using the clientcert=verify-full option combined with an additional authentication method in pg_hba.conf

PostgreSQL

Releasestatus Final
Besturingssystemen Windows 7, Linux, BSD, macOS, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016
Website PostgreSQL
Download https://www.postgresql.org/download/
Licentietype Voorwaarden (GNU/BSD/etc.)

Reacties (33)

33
33
24
5
0
7
Wijzig sortering
Fijne database. Gebruik het in combinatie met PostGIS voor verschillende GIS toepassingen.
Ik wil zelf ook wat aan de slag gaan met GIS vanwege de uitgebreide mogelijkheden. Ik vind het echter erg lastig om hier goed mee aan de slag te gaan. De PostGIS documentatie slaat al snel terug op GIS terminologie die ik dan niet echt begrijp. Heb je tips om hier meer wegwijs in te geraken?
Gis is haast een vak apart waar postgis en het Geometry data type een rol spelen in de opslag, en wat simpele vraag bewoording. Voor analyse en ontwikkeling heb je tools die tegenwoordig dicht tegen IDE's aanzitten, zoal open source desktop gis Qgis, en closed source (maar open standaarden zoals CIM, i3s, ogc, etc) ArcGIS pro. Er is serverside middleware zoals geoserver, mapbox, arcgis enterprise, etc, en ladingen renderer, waarbij zelfs game engines tellen, maar op web zie je veel leaflet, arcgis javascript, openlayers, Minecraft, etc...
Ik had al zo'n vermoeden. Ik gebruik al de earthdistance module zo kun je eenvoudig afstanden tussen twee plaatsen berekenen. Voor paden gebruik ik geometrische paths, maar dat werkt iets omslachtiger en de lengtes zijn niet te bereken. Ik wil dingen doen zoals kijken of paden overlappen met een kleine marge. Of kijken wat voor punten er in de buurt liggen van bepaalde routes.

Misschien is GIS dan een beetje een te lompe oplossing en moet ik de earth punten gewoon in een array stoppen en wat functies schrijven om bijvoorbeeld een afstand te berekenen.
Zoals Umbrah al zegt is GIS een heel vak. Wat helpt om er in een database mee aan de slag te gaan is om te beseffen dat geometrie gewoon een datatype is, net als date of numeric. Qgis desktop werkt goed samen met Postgres/PostGIS.
GIS zijn zelfs hele opleidingen. ;) Master en/of bachelor.

Ook GIS developer is een aparte functie. Dat is vaak lastig uit te leggen aan ontwikkelaars die zich vooral classificeren door de taal waarin ze ontwikkelen. Die begrijpen vaak weinig van de inhoudelijke materie en verwachten uit een functioneel ontwerp alle benodigde informatie te halen. Bij GIS vraagstukken gaat die vlieg gewoon niet op.
Als je dit beschikbaar hebt, hoe hebben MSSQL en Oracle dan nog bestaansrecht? Serieuze vraag waar ik zelfs van doorgewinterde dba's weinig anders op terug krijg dan dat de applicatie nu eenmaal tegen die of die DB is geschreven. Maar waarom zou je dat dus nog doen?
Anoniem: 69322 @BvdW19785 oktober 2019 21:08
Het is ook geen vraag die je aan de typische DBA moet vragen, want die maken normaal gesproken niet veel applicaties. Veel zien dus maar 1 kant van een oplossing, en hetzelfde zie je aan de applicatie kant en dat is ook een groot probleem. Een competente ontwikkelaar kan allebei en implementeert functionaliteit waar ze het beste passen.

Maar gelukkig doe ik beide en kan je antwoord geven. Microsoft Server is heel geschikt voor maatwerk applicaties. Wat zeker beter kan zijn de nieuwe meer geavanceerde features, maar dat is bij de competitie net zo (als ze de features al hebben).

Het is ook nog eens goedkoper dan de concurrentie, ja zelfs de gratis software. Wat voor maatwerk belangrijk is, is een goede rijke basis waar gemakkelijk voor te ontwikkelen is. Ontwikkeltijd is namelijk het duurste van software ontwikkeling en niet de licentie kosten. Voor geen enkel bedrijf zal enkele tientjes per core per maand een probleem vormen! En daarnaast zijn er ook nog cloud oplossingen!

De kunstmatige editie segmentering, daar ben ik niet echt een fan van, maar sinds versie 2016 SP1 zijn de meeste technische nadelen daarvan wel verholpen. Je kunt sindsdien vrijwel alle programmeer relevante features ook in de laagste (zelfs gratis) editie gebruiken.

Ze ook mijn kritiek elders in deze thread op wat ik in deze patch van PostgreSQL tegen kwam.

[Reactie gewijzigd door Anoniem: 69322 op 24 juli 2024 13:12]

Maar gelukkig doe ik beide en kan je antwoord geven. Microsoft Server is heel geschikt voor maatwerk applicaties. Wat zeker beter kan zijn de nieuwe meer geavanceerde features, maar dat is bij de competitie net zo (als ze de features al hebben).

Het is ook nog eens goedkoper dan de concurrentie, ja zelfs de gratis software. Wat voor maatwerk belangrijk is, is een goede rijke basis waar gemakkelijk voor te ontwikkelen is. Ontwikkeltijd is namelijk het duurste van software ontwikkeling en niet de licentie kosten. Voor geen enkel bedrijf zal enkele tientjes per core per maand een probleem vormen! En daarnaast zijn er ook nog cloud oplossingen!
Voor maatwerk klopt dat wel. Het wordt een ander verhaal als het software is die bij tientallen of honderden organisaties draait.
Niet verstandig om tegenwoordig nog een applicatie te ontwikkelen zonder ORM (zoals Hibernate voor Java) te gebruiken. Dan zit je niet vast aan de RDBMS (PostgreSQL, Oracle, MariaDB etc.).

Ik denk ook dat grote bedrijven Oracle of MSSQL gebruiken voor de ondersteuning die ze krijgen.
ORMs zijn een ramp voor een database en applicatie performance en mogelijkheden. Het is meer een voortvloeisel om maar vooral geen nieuwe kennis op te doen en in de favorite taal te blijven werken.

Leer gewoon SQL goed te gebruiken en er gaat een wereld voor je open. Je denkt dan hoe je het ooit zonder hebt kunnen doen en hoe krom en duur de op andere manieren gemaakte oplossingen zijn.

Een micro ORM is prima, maar schrijf echt zelf je SQL voor het platform waarop je wil gaan draaien. Het komt zo goed als nooit voor dat je meer dan 1 platform wil gaan ondersteunen. Maar als het dan toch een keer gebeurd is het herschrijven of dubbel schrijven dan de queries echt niet het grote probleem.

[Reactie gewijzigd door Anoniem: 69322 op 24 juli 2024 13:12]

Dat is echt onzin. Er is niks mis met het gebruik van een ORM. Een ORM lost veel problemen op die je zal creëren als je alles zelf doet.
Tenzij je een triviale applicatie maakt is de beste aanpak om te beginnen met ORM, en pas als performance, of mogelijkheden een probleem vormen over te gaan naar SQL. Veel ORMs hebben ook de mogelijkheid om de ORM te versterken met optimized hand-written SQL.
Ik zie de replicatie van postgresql nog niet doen wat Oracle doet icm golden gate. Misschien is dat een antwoord. Helaas wel want verder is postgresql een geweldig mooi product.
Anoniem: 69322 5 oktober 2019 19:07
Het valt me op dat er nog zoveel basic features tussen zitten die bij SQL Server al meerdere versies standaard zijn. En het nu ook weer niet het geval dat PostgeSQL een nieuwe ontwikkeling is. Ik denk dan aan het gebruik van verschillende collations, included columns bij indexes, persisted computed columns, concurrent re-indexing (online in SQL Server) en Json navigatie.

Altijd maar veel poeha gelezen, vroeger vooral over MySQL en tegenwoordig meer en meer over PostgreSQL. Maar iedere keer blijkt het toch niets te bevatten waarvoor een switch ook maar ensigns realistisch lijkt. En alles loopt gewoon ver achter zie ik dan. En als ik dan eens Oracle code zie dan denk ik ook dat het niet eens een serieuze RDBMS te noemen is (vanuit een praktisch perspectief).

Nu heb ik ook zo mijn kritiek op enkele implementaties binnen SQL Server, maar ze hebben bij Microsoft duidelijk toch beter in kaart waar behoefte aan is dan de vermeende concurrentie. Het kan natuurlijk ook daar nog veel beter, maar dat is weer een ander verhaal omdat de basics gewoon goed zijn te noemen.

[Reactie gewijzigd door Anoniem: 69322 op 24 juli 2024 13:12]

Het valt me op dat er nog zoveel basic features tussen zitten die bij SQL Server al meerdere versies standaard zijn.
Blijkbaar is/was er weinig behoefte aan, anders had iemand het al wel (eerder) opgepakt.
En alles loopt gewoon ver achter zie ik dan.
Zoals? En niet alles wat jij nodig hebt, heeft een ander ook nodig. Daarnaast kun je problemen soms ook oplossen door het compleet anders aan te pakken, waardoor je de voor jou bekende functionaliteit helemaal niet nodig hebt omdat oplossing X of Y ook werkt. Alleen werkt het anders.

De eindklant wil van A naar B komen, het interesseert ze vaak geen drol hoe je daar komt. Mits het niet teveel tijd en geld kost.
Voor verreweg de meeste toepassingen is al die extra cruft gewoon niet nodig. Wij verschepen jaarlijks honderdduizenden apparaten met postgre databases. Ook management en correlation draaien op postgre.

Die paar procent toepassingen waar het niet toereikend is mogen MS en Oracle het uitvechten. Een groot deel van het internet (infrastructuur) draait direct of indirect op postgre tegenwoordig.
Anoniem: 69322 @Belgar5 oktober 2019 19:44
Wat er binnen embedded systemen gebeurd, daar heb ik geen zicht op. Dus je kan best gelijk in hebben dat de huidige basics prima volstaan voor die toepassingen (en andere eigenschappen belangrijk zijn).

Maar vergeet dan ook niet dat tegenwoordig zo goed als alle software die bedrijven gebruiken over web-interfaces en API's gaan. Deze software en andere custom software werkt dan meestal met een RDBMS voor de data-opslag.

Dat is echt het grootste onderdeel van het web te noemen en bovendien de plek waar de waarde van het internet en geschreven software worden bepaald. Hier komt heel veel maatwerk bij kijken en dus heel veel ontwikkeltijd door heel veel partijen.

Bekeken vanuit het perspectief van de betrokken ontwikkeltijd is het belangrijk om juist die markt goed te bedienen. De grootste groep ontwikkelaars zit echt niet in de hoek van embedded systems. Waar jij denkt dat het een paar procent betreft zal het in werkelijkheid ergens boven de 90% moeten zitten!

Van mijn nu bijna 30 jaar professioneel software ontwikkelen is zelfs voor de opkomst van het internet de behoefte aan maatwerk software draaiende op databases bij bedrijven nooit afgenomen. Dus ik kan best wel stellig zijn dat daar de grootste gebruikers zitten van databases w.b.t. ontwikkeltijd en investeringen.

[Reactie gewijzigd door Anoniem: 69322 op 24 juli 2024 13:12]

Ik vond de opmerking over apparaten ook een beetje vreemd, en als de "paar procent"-suggestie ging over (het inverse van) de marktpenetratie van PostgreSQL, dan zet ik daar ook vraagtekens bij. Maar ik geloof wel dat het overgrote deel van de applicaties in de wereld geen Oracle, SQL Server of DB2 nodig heeft. Helaas, zou ik zeggen, is het marktaandeel van die producten nog altijd groter dan nodig, dankzij de marketing en de politiek ("no one got ever fired for buying IBM"-achtige toestanden).

PostgreSQL is echt een geweldige database, en voor veel toepassingen meer dan voldoende.
Ik melde specifiek de infrastructuur van het web. Routers, management systems etc. Ook veel van de interne systemen in datacenters zelf.

Applicaties is een ander verhaal en daar zit inderdaad een groot deel van het werk voor ontwikkelaars, maar het volwassen worden van postgre voor algemene toepassingen als een stabiele gratis database is heel belangrijk geweest voor enorm veel dagelijkse toepassingen
Anoniem: 69322 5 oktober 2019 19:24
Zojuist lees ik over "Nondeterministic Collations".

https://www.postgresql.or...OLLATION-NONDETERMINISTIC

Men lijkt niet echt te weten wat deterministic betekend en beschrijven het als een byte comparison van data in deze context. Wat natuurlijk complete onzin is, deterministic is dat een uitkomst van een vergelijking met dezelfde input en begin situatie ook altijd dezelfde output geeft. Wat de vergelijkingsregels precies zijn, doet er niet eens toe!

Dit soort beschrijvingen geven me alles behalve een goed vertrouwen in het product of de mensen die achter de schermen de beslissingen nemen. Sorry voor wie zijn ziel aan het product verbind, maar ik ben niet echt onder de indruk.
In datzelfde stukje tekst staat "See also Unicode Technical Standard 10 for more information on the terminology.". Men weet dus precies wat deterministic in deze context betekent.

Een dergelijke inhoudelijke kennis van minstens de Unicode standaard bij de Postgresql ontwikkelaars geeft mij juist een enorm vertrouwen in het product.
maar ik ben niet echt onder de indruk.
Dat was ook niet het doel van deze release... O+

Al kun je daar wellicht nog wel een functie voor schrijven, bijvoorbeeld in pl/perl
In een reactie van een oudere versie werd gevraagd om een update van pgadmin3.

Deze is inmiddels vervangen door versie 4.
https://www.pgadmin.org/download/
PGAdmin 4 is in veel aspecten een compleet ander pakket, en hoewel het gelukkig tegenwoordig >uit< z'n QML eigen "browser" is gegaan naar de systeembrowser, blijft het qua responsiveness en effectiviteit zo ontzettend ver achter op Oracle SQL Developer. Microsoft SQL Studio, en... PGAdmin 3. Ik gebruik het zelf ook, noodgedwongen, maar een backport naar PGAdmin 3 zal fijn zijn... zodat ik 4.x niet hoef te gebruiken...
Ik ben persoonlijk heel blij met HeidiSQL's ondersteuning voor PostgreSQL, ik weet niet of je die al geprobeerd hebt?
Pas ontdekt maar nu al fan: https://tableplus.com/ Er worden bijna wekelijks nieuwe features toegevoegd door de ontwikkelaars.

[Reactie gewijzigd door vdws op 24 juli 2024 13:12]

Ik gebruik DBeaver, maar zal ook eens kijken naar de alternatieven die hier genoemd worden
Probeer niet HeidiSQL, want de PostgreSQL ondersteuning daarvan is slecht. Ik kwam ook uit op DBeaver, omdat PGAdmin 4 te slecht was.
Hoewel niet gratis is DataGrip van Jetbrains wat mij betreft toch echt wel de nummer 1. Overzichtelijk, vol met features, stabiel en ondersteuning voor veel databases.

https://www.jetbrains.com/datagrip/
En hier een tevreden gebruiker van Navicat, werkt ook op OS X en met diverse databases. Het is niet gratis, maar het kost ook geen duur geld.
Zijn er mensen die vroeger MySQL gebruikten en ondertussen overgestapt zijn naar Postgres ?
Wat zijn jullie ervaringen daarmee ?
Louter positief. Pakweg 20 jaar geleden al eigenlijk. Toen had ik MySQL welgeteld één paar minuten geïnstalleerd gehad, maakte een tabel met primaire sleutel en mocht deze gewoon dubbel opvoeren, kwam er ook dubbel in. Dat heeft mij meteen verder doen kijken. Jaren later een paar keer MySQL door PostgreSQL vervangen, eerst voor een beter relationeel model, en later, grappig genoeg voor performance. PostgreSQL werd in het verleden gemeden vanwege tegenvallende performance tov MySQL, in een database met veel concurrent writes zagen we een enorm verschil in performance, waarbij op dezelfde hardware out of the box, PostgreSQL en factor 10 of meer sneller performer. En grote resultaat sets, waar MySQL nog wel eens op wilde crashen waren geen enkel issue. Ik zou zeggen dat op alle fronten PostgreSQL de veel betere keuze is tussen deze twee. (Plus MySQL is nu van Oracle, dat is al een reden op zich. Dan is MariaDB wat logischer, maar bevat nog alle flaws van MySQL)
Las gisteren dat Percona ook PostgresSQL gaat ondersteunen.
https://www.theregister.c...sql_and_mongodb_products/

Op dit item kan niet meer gereageerd worden.