From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Michael Lewis <mlewis(at)entrata(dot)com> |
Cc: | Jonathan Marks <jonathanaverymarks(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Forcing index usage |
Date: | 2019-04-03 18:44:25 |
Message-ID: | 20190403184425.GG6197@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Greetings,
* Michael Lewis (mlewis(at)entrata(dot)com) wrote:
> > Is there a way to tell Postgres “please don’t use index X when queries
> > that could use index Y instead occur?”
>
> No. But you could re-write the query to make the date index useless. The
> simplest way that comes to mind is putting the query that does your
> full-text search in a CTE (WITH keyword, it is an optimization boundary)
> and then ordering and applying your limit to the materialized set that
> comes out of that. eg.
>
> WITH cte_full_text_results AS(
> SELECT date, result FROM big_a_table WHERE text = 'whatever'
> )
> SELECT * FROM cte_full_text_results ORDER BY date DESC limit 10;
Note that in v12, you'll need to include the MATERIALIZE keyword,
otherwise we'll in-line the CTE and you might get the plan you don't
like. That said, it seems a bit unfortunate that there's no clear way
to create an index which specifically answers this query; figuring out a
way to do that could be very beneficial in a number of areas. The RUM
index type attempts to improve things here, as I understand it.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Rob Sargent | 2019-04-03 18:58:54 | Re: stale WAL files? |
Previous Message | Perumal Raj | 2019-04-03 17:02:00 | Re: Recommendation to run vacuum FULL in parallel |