Re: Hstore index for full text search

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Lewis <mlewis(at)entrata(dot)com>
Cc: Burhan Akbulut <burhan(dot)akbulut(at)cooksoft(dot)com(dot)tr>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Hstore index for full text search
Date: 2020-08-11 23:30:58
Message-ID: 71100.1597188658@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Michael Lewis <mlewis(at)entrata(dot)com> writes:
> On Tue, Aug 11, 2020 at 4:46 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Another point is that you will only
>> get an indexscan if *every* OR'd clause matches some index. The example
>> query looks sufficiently unstructured that that might be hard to ensure.

> Does this still apply when the where clauses are on several tables and not
> just one?

Yeah. In that case there's no hope of an indexscan at all, since for all
the planner knows, the query might match some table rows that don't meet
any of the conditions mentioned for that table's columns. If you can
write

WHERE (condition-on-t1.a OR condition-on-t1.b OR ...)
AND (condition-on-t2.x OR condition-on-t2.y OR ...)

then you've got a chance of making the OR'd conditions into index
qualifications on t1 or t2 respectively. But if it's

WHERE condition-on-t1.a OR condition-on-t1.b OR ...
OR condition-on-t2.x OR condition-on-t2.y OR ...

then you're in for full-table scans. (This is another thing that
was bothering me about the data design, though I failed to think
it through clearly enough to state before.)

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ken Tanzer 2020-08-14 21:34:52 Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query
Previous Message Jim Jarvie 2020-08-11 22:58:29 Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?