{"id":144010,"date":"2025-09-25T17:11:55","date_gmt":"2025-09-25T15:11:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/reliz-subd-postgresql-18"},"modified":"2025-09-25T17:11:55","modified_gmt":"2025-09-25T15:11:55","slug":"reliz-subd-postgresql-18","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/news\/reliz-subd-postgresql-18","title":{"rendered":"Udgivelsen af databasen PostgreSQL 18.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Efter et \u00e5rs udvikling er den nye stabile version af databasesystemet PostgreSQL 18 blevet udgivet. Opdateringer til den nye version vil blive udgivet i fem \u00e5r frem til november 2030. St\u00f8tten til PostgreSQL 13.x, den \u00e6ldste af de underst\u00f8ttede versioner, vil blive afsluttet den 13. november. <\/p>\n
Hovednyhederne: <\/p>\n
\n
Der er tilf\u00f8jet et subsystem til asynkron ind- og uddata, som \u00f8ger b\u00e5ndbredden for ind- og uddata og eliminerer forsinkelser. Udover den universelle AIO-implementering (io_method=worker), der er tilg\u00e6ngelig p\u00e5 alle platforme og baseret p\u00e5 flere behandlingsprocesser (som standard 3), kan der i Linux anvendes gr\u00e6nsefladen til asynkron ind- og uddata io_uring (io_method=io_uring), som underst\u00f8ttes fra Linux-kernen 5.1. Asynkron ind- og uddata anvendes i \u00f8jeblikket kun til at accelerationere visse operationer relateret til l\u00e6sning af data fra filsystemet, s\u00e5som sekventiel iterering, scanning af indeksbitmap og udf\u00f8relse af oprydning (vacuum). I nogle tests f\u00f8rer brugen af AIO til en stigning i ydeevnen p\u00e5 2-3 gange. Skriveoperationer forts\u00e6tter med at blive udf\u00f8rt synkront for at opfylde kravene til ACID.\n
Optimering af \"skip scan\" i multis\u00f8jlene indekser er realiseret, hvilket g\u00f8r det muligt at bruge indekset ikke kun til at kontrollere den f\u00f8rste indekserede s\u00f8jle og den fulde sammenkobling af s\u00f8jler, men ogs\u00e5 til at behandle de \u00f8vrige indekserede s\u00f8jler enkeltvis. For eksempel, tidligere blev der ved oprettelse af en B-tree indeks over s\u00f8jlerne \"(status, dato)\" kun anvendt indekset til foresp\u00f8rgsler, der kontrollerede feltet \"status\" eller begge felter \"status\" og \"dato\"; men ved kun at kontrollere feltet \"dato\" skulle tabelens indhold scannes. \"Skip scan\" tilstanden muligg\u00f8r i bestemte situationer scanning af indekset ved foresp\u00f8rgsler om kun feltet \"dato\". Denne tilstand anvendes kun for \"B-tree\" indekser, n\u00e5r der anvendes operatoren \"=\" p\u00e5 det indekserede felt i situationer, hvor det udeladte felt har et lille antal forskellige v\u00e6rdier (for eksempel vil optimeringen fungere, hvis status feltet \"status\" har et par faste v\u00e6rdier).\n
Der er tilf\u00f8jet optimeringer, der mere effektivt bruger indekser til foresp\u00f8rgsler, der indeholder konstruktioner som \"OR\" og \"IN (...)\" i \"WHERE\" blokken, samt \u00f8ger ydeevnen ved planl\u00e6gning og udf\u00f8relse af tabel sammenkoblinger (for eksempel er koden til sammenfletning af hashes blevet hurtigere, og inkrementel sortering er blevet tilladt under sammensmeltning af tabeller).\n
Der er tilf\u00f8jet support til parallelisering af opbygningen af GIN (Generalized Inverted Index) indekser, der anvendes til indeksering af sammensatte v\u00e6rdier som arrays og til organisering af s\u00f8gning i fuldtekstdata eller JSON-strukturer.\n
Muligheden for at oprette materialiserede visninger og n\u00f8gler til partitionering af tabeller med indekser med \"unique\" flag, der ikke bruger B-tree strukturen, er blevet tilf\u00f8jet.\n
Den samlede ydeevne for l\u00e5sning af foresp\u00f8rgsler, der arbejder med mange tabeller, er forbedret, og der er ogs\u00e5 lavet forbedringer i h\u00e5ndteringen af foresp\u00f8rgsler til sektionerede tabeller, hvilket accelererer filtreringen af ubrugte sektioner og sammenf\u00f8jninger (JOIN).\n
Tekstoperationer, s\u00e5som funktioner til at konvertere til store\/sm\u00e5 bogstaver, er blevet accelereret. Der er tilf\u00f8jet en PG_UNICODE_FAST-tilstand for at fremskynde h\u00e5ndteringen af Unicode-tegns lokalitetsegenskaber.\n
Muligheden for at gemme statistik for sp\u00f8rringsplanl\u00e6ggeren efter opdatering mellem st\u00f8rre udgivelser af PostgreSQL er blevet realiseret. \u00c6ndringen g\u00f8r det muligt at undg\u00e5 at udf\u00f8re den ressourcekr\u00e6vende operation \"ANALYZE\" efter opdatering til en ny version, der tidligere har resulteret i nedsat ydeevne for databasen.\n
Ydelsen for pg_upgrade, som anvendes til at automatisere overgangen til nye v\u00e6sentlige udgivelser af PostgreSQL, har f\u00e5et en pr\u00e6stationsforbedring. Optimeringerne er s\u00e6rligt m\u00e6rkbare ved opdatering af databaser, der indeholder mange objekter, s\u00e5som tabeller og sekvenser. For at fremskynde pg_upgrade er der ogs\u00e5 tilf\u00f8jet flaget «—jobs N» for at parallelisere kontroller i N tr\u00e5de og flaget «—swap» for helt at erstatte datakataloger uden at oprette links, uden kloning og uden at kopiere filer.\n
Underst\u00f8ttelse af virtuelle genererede kolonner, hvis v\u00e6rdier beregnes on-the-fly under k\u00f8rslen af foresp\u00f8rgsler, uden at blive gemt p\u00e5 disken, er tilf\u00f8jet. Hvis der i udtrykket «CREATE TABLE…» for genererede kolonner kun er angivet n\u00f8gleordet «GENERATED» uden at specificere type (STORED eller VIRTUAL), anvendes den nye variant som standard i stedet for den gamle implementering. I den gamle implementering blev v\u00e6rdier genereret under k\u00f8rslen af «INSERT» eller «UPDATE» operationer og gemt p\u00e5 disken til senere brug. Ulempen ved virtuelle genererede kolonner er, at de ikke kan bruges i indekser, mens fordelen er muligheden for at udf\u00f8re normalisering og \u00e6ndring af data on-the-fly (relevant n\u00e5r der arbejdes med JSON-data). Hvad ang\u00e5r de klassiske lagrede genererede kolonner, er der i den nye udgave tilf\u00f8jet st\u00f8tte til logisk replikation.\n
I kommandoerne INSERT, UPDATE, DELETE og MERGE er det nu muligt at vise tidligere (OLD) og nuv\u00e6rende (CURRENT) v\u00e6rdier i udtrykket RETURNING. For eksempel, «UPDATE… RETURNING WITH (OLD AS o, NEW AS n) o.*, n.*.».\n
Funktionen uuidv7() er tilf\u00f8jet til at generere tilf\u00e6ldige unikke identificatorer i UUIDv7-format. I mods\u00e6tning til den gamle funktion til at generere UUID (gen_random_uuid), der nu ogs\u00e5 er tilg\u00e6ngelig som uuidv4(), inkluderer UUIDv7 udover tilf\u00e6ldig v\u00e6rdi ogs\u00e5 tidspunktet for genereringen. Tilstedev\u00e6relsen af ordnede dele i UUID-v\u00e6rdien (de f\u00f8rste 12 tegn \u2014 epoch-tid, og de f\u00f8lgende 18 \u2014 tilf\u00e6ldig v\u00e6rdi) forbedrer effektivitet ved sortering og indeksering, hvilket er relevant, da UUID normalt bruges til prim\u00e6re n\u00f8gler (for eksempel placeres n\u00f8gler, der er oprettet p\u00e5 t\u00e6t tidspunkt, t\u00e6ttere i indekset).\n
I operationen «LIKE» er der indf\u00f8rt support til tekstmatches, som bruger ikke-deterministiske lokalitetsindstillinger «collation», der g\u00f8r det muligt at udf\u00f8re matches med hensyn til betydningen af tegn (for eksempel kan accenter ignoreres ved sammenligning). Der er tilf\u00f8jet en CASEFOLD-funktion til at \u00e6ndre tegns case under hensyntagen til lokalitetsindstillingerne «collation» (for eksempel kan nogle tegn have mere end to sm\u00e5 bogstaver eller kr\u00e6ve konvertering til store bogstaver i stedet for sm\u00e5 ved sammenligning).\n
Muligheden for at bruge tidsbegr\u00e6nsninger (temporal constraint) er blevet tilf\u00f8jet. I v\u00e6rdierne «PRIMARY KEY» og «UNIQUE» skal udtrykket «WITHOUT OVERLAPS» bruges til at tilf\u00f8je tidsbegr\u00e6nsninger, mens udtrykket PERIOD skal bruges i v\u00e6rdien «FOREIGN KEY». For eksempel kan man ved definition af prim\u00e6re n\u00f8gler begr\u00e6nse n\u00f8gler med overlappende tidsintervaller.\n
Der er tilf\u00f8jet kommandoen «CREATE FOREIGN TABLE … LIKE command» til at oprette skemaet for en ekstern tabel baseret p\u00e5 definitionen af en lokal tabel.\n
Support til at oprette forbindelse til databaser ved hj\u00e6lp af OAUTH 2.0-godkendelse med adgangstoken i stedet for adgangskode er blevet tilf\u00f8jet. Anvendelse af OAUTH muligg\u00f8r ikke at gemme adgangskoder i databasen, men identificerer brugere gennem eksterne tjenester, samt udnytte funktioner som to-faktorautentifikation og single sign-on (SSO).\n
Funktionen ssl_tls13_ciphers() er blevet tilf\u00f8jet, som g\u00f8r det muligt at bestemme listen over godkendte krypteringsalgoritmer ved tilslutning ved hj\u00e6lp af protokollen TLSv1.3.\n
Underst\u00f8ttelse af godkendelse med brug af md5-algoritmen til hashing af adgangskoder er blevet klassificeret som for\u00e6ldet og planlagt til fjernelse. I stedet anbefales det at bruge SCRAM-algoritmen (SCRAM-SHA-256), som blev introduceret i PostgreSQL 10. Der skal desuden bem\u00e6rkes implementeringen af SCRAM-godkendelse ved tilslutning via postgres_fdw og dblink til eksterne PostgreSQL-servere.\n
Ved udf\u00f8relse af operationen «EXPLAIN ANALYZE» er der sikret output af oplysninger om antallet af indeks-s\u00f8geoperationer ved scanning af indeks og antallet af bufferanmodninger under udf\u00f8relsen af foresp\u00f8rgslen. Der er inkluderet CPU-statistik, WAL-log og intensitet af l\u00e6seoperationer i output «EXPLAIN ANALYZE VERBOSE». Tabellen pg_stat_all_tables er blevet tilf\u00f8jet med oplysninger om den tid, der er brugt p\u00e5 VACUUM-operationen og analyse af tabeller. Der er leveret data om input\/output-intensiteten og belastningen p\u00e5 WAL-loggen opdelt efter enkelte forbindelser. Diagnostik om konflikter under skriveoperationer under logisk replikation er blevet tilf\u00f8jet til pg_stat_subscription_stats og logs.\n
I nye installationer er brugen af kontrolsummer til at tjekke integriteten af de gemte data som standard aktiveret. For at annullere denne adf\u00e6rd under initdb skal man angive indstillingen «—no-data-checksums».\n
Flaget «—all» er blevet tilf\u00f8jet til v\u00e6rkt\u00f8jet pg_createsubscriber for at oprette logiske replikater med \u00e9n kommando for alle databaser.\n
En ny version (3.2) af protokollen, der anvendes til kommunikation mellem eksterne v\u00e6rkt\u00f8jer og DBMS, er implementeret i biblioteket libpq. Den forrige opdatering af protokollen blev udf\u00f8rt i PostgreSQL 7.4 (2003). I biblioteket libpq anvendes version 3.0 som standard. <\/ul>\n