Jodå, relid ligger det index på, åtminstone. Men en annan sak har slagit mig vad gäller found_rows(); i många funktioner brukar jag fetcha resultatet (säg de 10 jag limitat fram) med pg_fetch_all() istället för att loopa och fetcha dem med pg_fetch_assoc(), vilket jag har fått för mig är snabbare.
Men om jag nu ska migrera till att hämta samtliga rader och endast itera över de som har intresse kan det ju (väl?) inte vara någon bra idé att köra med pg_fetch_all(), eftersom det innebär att en jättevektor kommer att returneras. Och pg_fetch_all() är ju en funktion som jag bara älskar...
Så frågan är lite vad göra?
* found_rows()-ekvivalent verkar inte finnas, så det är bara att glömma
* limit funkar ju istället, och är det sätt som jag måste köra med om jag vill använda pg_fetch_all()
* eller så kan jag hämta allt och antingen itera över relevanta rader och lägga till dem till min returvektor och returnera en vektor med längden [antal i limit] i första dimensionen, eller hämta _allt_ till en vektor med pg_fetch_all(), för att sedan returnera denna. Kanske snabbare än iteration så länge man håller sig under ett visst antal, men med ett par tio tusen rader i databasen kanske det kan bli lite svårhanterat för php...
Kanske är det bäst att hämta alla rader, och sedan itera över de rader som är relevanta och som man vill returnera. Detta har 2 st fördelar: eftersom funktionen xx_fetch_all() inte finns för mysql, håller man sin pg-php-lösning portningsbar mot mysql, och eftersom inte found_rows() ingår i SQL-syntaxen, blandar man inte in otrevliga, ostandardiserade funktioner i sin kod... hmmm...
Well well, feed back och kommentarer är välkommet... Även om jag antar att det mest blir du, Samuel, som svarar - vi verkar vara de enda postgressarna här....