Hi Tom, thanks for your reply, much appreciated.
So basically you're saying it's hard to do sorting in any way when a gin
index is involved? Neither with a complete multi-column btree_gin index
because it doesn't support sorting per definition, nor with a seperate
gin and btree because there would be an extra post-sorting step involved
over the FULL resultset (because of the LIMIT).
Then would you have any hint on how to implement pagination when doing
full text search?
Cause in theory, if I gave it a id>100 LIMIT 100, it might just as well
return me results 150 to 250, instead of 100 to 200...
PS: I already tried maxing the statistics target setting and running
ANALYSE after, with no change.
Regards,
Jordi
On 04-02-16 17:08, Tom Lane wrote:
Jordi <jmaillists@xxxxxxxxxx> writes:
I've been trying to get a query use indexes and it has raised a doubt
whether pgsql supports bitmap and-ing between a multi-column btree index
and a gin index.
Sure. But such a plan would give an unordered result, meaning that we'd
have to process the whole table before doing the ORDER BY/LIMIT. The
planner evidently thinks that it's better to try to process the rows in
ID order so it can stop as soon as it's got 100. If it's wrong about
that, that's likely because it's got a bad estimate of the selectivity of
the other WHERE conditions. You might see if you can improve the
statistics for the search_vector column.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
