Markører er et rimeligt valg til personsøgning i mindre intranetapplikationer, der fungerer med store datasæt, men du skal være forberedt på at kassere dem efter en timeout. Brugere kan lide at gå rundt, gå til frokost, tage på ferie i to uger osv. og lade deres applikationer køre. Hvis det er en webbaseret app, er der endda spørgsmålet om, hvad "løb" er, og hvordan man kan se, om brugeren stadig er i nærheden.
De er ikke egnede til applikationer i stor skala med højt klientantal og klienter, der kommer og går næsten tilfældigt som i webbaserede apps eller web-API'er. Jeg vil ikke anbefale at bruge markører i din applikation, medmindre du har et ret lille klientantal og meget høje anmodningsrater ... i så fald vil det være meget ineffektivt at sende små batches af rækker, og du bør overveje at tillade range-anmodninger osv. i stedet.
Markører har flere omkostninger. Hvis markøren ikke er WITH HOLD du skal holde en transaktion åben. Den åbne transaktion kan forhindre autovacuum i at udføre sit arbejde korrekt, hvilket forårsager bordoppustethed og andre problemer. Hvis markøren er erklæret WITH HOLD og transaktionen ikke holdes åben, skal du betale omkostningerne ved at materialisere og opbevare et potentielt stort resultatsæt - i det mindste tror jeg, at det er sådan hold-markører fungerer. Alternativet er lige så dårligt, at holde transaktionen implicit åben, indtil markøren er ødelagt, og forhindre rækker i at blive ryddet op.
Derudover, hvis du bruger markører, kan du ikke videregive forbindelser tilbage til en forbindelsespulje. Du skal bruge én forbindelse pr. klient. Det betyder, at der bruges flere backend-ressourcer, blot ved at opretholde sessionstilstand, og sætter en meget reel øvre grænse for antallet af klienter, du kan håndtere med en markørbaseret tilgang.
Der er også kompleksiteten og overheaden ved at administrere en tilstandsfuld, markørbaseret opsætning sammenlignet med en tilstandsløs forbindelsespooling-tilgang med grænse og offset. Du skal have din applikation til at udløbe markører efter en timeout, ellers står du over for potentielt ubegrænset ressourcebrug på serveren, og du skal holde styr på hvilke forbindelser der har hvilke markører for hvilke resultatsæt for hvilke brugere...
Generelt, på trods af at det kan være ret ineffektivt, LIMIT og OFFSET kan være den bedre løsning. Det kan ofte være bedre at søge efter den primære nøgle frem for at bruge OFFSET dog.
Du så i øvrigt på dokumentationen for markører i PL/pgSQL. Du vil have normale markører på SQL-niveau til dette job.
Kræver markørerne, at en databaseforbindelse efterlades åben?
Ja.
Kører markørerne inde i en transaktion og låser ressourcer, indtil de er "lukket"?
Ja, medmindre de er WITH HOLD , i hvilket tilfælde de bruger andre databaseressourcer.
Er der andre "gotchas", som jeg ikke er klar over?
Ja, som ovenstående burde forklare.