pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedBitmap and-ing between btree and gin?
4+ messages / 3 participants
[nested] [flat]
* Bitmap and-ing between btree and gin?
@ 2016-02-04 11:15 Jordi <jmaillists@promani.be>
0 siblings, 1 reply; 4+ messages in thread
From: Jordi @ 2016-02-04 11:15 UTC (permalink / raw)
To: pgsql-performance
Hello all,
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.
The idea is to do a full-text search on a tsvector that is indexed with
gin. Then there are typical extra filters like is_active that you would
put in a btree index. Instead of using OFFSET I use a > operation on the
id. Finally, to make sure the results listing always appear in the same
order, I do an ORDER BY the id of the row. So something like this:
CREATE INDEX idx_gin_page ON page USING gin(search_vector);
CREATE INDEX idx_btree_active_iddesc ON page USING btree(is_active, id DESC);
SELECT * FROM page WHERE (( (page.search_vector) @@ (plainto_tsquery('pg_catalog.english', 'myquery'))) AND page.is_active = 1 AND page.id > 100) ORDER BY page.id DESC LIMIT 100;
Some options I considered:
- One big multi-column index with the btree_gin module, but that didn't
work. I suppose it's because just like gin, it doesn't support sorting.
- Seperate indexes as above, but that didn't work. The planner would
always choose the btree index to do the is_active=1 and id>100 filter
and the sorting, and within those results do a manual filter on the
tsvector, being extremely slow.
BUT: when I remove the ORDER BY statement, the query runs really fast.
It uses the 2 indexes seperately and bitmap-ands them together,
resulting in a fast executing query.
So my question is whether there is something wrong with my query or
indexes, or does pgsql not support sorting and bitmap and-ing?
Thanks and have a nice day
Jordi
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Bitmap and-ing between btree and gin?
@ 2016-02-04 16:08 Tom Lane <tgl@sss.pgh.pa.us>
parent: Jordi <jmaillists@promani.be>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2016-02-04 16:08 UTC (permalink / raw)
To: Jordi <jmaillists@promani.be>; +Cc: pgsql-performance
Jordi <jmaillists@promani.be> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Bitmap and-ing between btree and gin?
@ 2016-02-04 17:19 Jordi <jmaillists@promani.be>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Jordi @ 2016-02-04 17:19 UTC (permalink / raw)
To: pgsql-performance; +Cc: tgl@sss.pgh.pa.us
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@promani.be> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Bitmap and-ing between btree and gin?
@ 2016-02-08 18:13 Jeff Janes <jeff.janes@gmail.com>
parent: Jordi <jmaillists@promani.be>
0 siblings, 0 replies; 4+ messages in thread
From: Jeff Janes @ 2016-02-08 18:13 UTC (permalink / raw)
To: Jordi <jmaillists@promani.be>; +Cc: pgsql-performance; Tom Lane <tgl@sss.pgh.pa.us>
On Thu, Feb 4, 2016 at 9:19 AM, Jordi <jmaillists@promani.be> wrote:
The custom here is to respond in line, not to top-post. Thanks.
>
> 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).
In principle there is no reason (that I can think of) that a normal
btree index range scan couldn't accept a bitmap as an optional input,
and then use that as a filter which would allow it to walk the index
in order while throwing out tuples that can't match the other
conditions. You are not the first person who would benefit from such
a feature. But it would certainly not be trivial to implement. It is
not on anyone's to-do list as far as I know.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2016-02-08 18:13 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-02-04 11:15 Bitmap and-ing between btree and gin? Jordi <jmaillists@promani.be>
2016-02-04 16:08 ` Tom Lane <tgl@sss.pgh.pa.us>
2016-02-04 17:19 ` Jordi <jmaillists@promani.be>
2016-02-08 18:13 ` Jeff Janes <jeff.janes@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox