Divide and conquer. Get rid of the CTE temporarily.
create temp table temp_search as ;
-- index temp_search *appropriately*
analyze temp_search;
Use it instead of the CTE.
Remove the ORDER BY temporarily.
Work on putting the right indices in place to make the above run fast.
I assume you h
Greg Sabino Mullane writes:
> Please provide a self-contained use case, or (at the bare minimum) trim out
> the irrelevant parts of your query and show us the schema for the tables in
> question. Finally, please show the explain plans for the "good" and "bad"
> runs you are experiencing. Thanks.
Please provide a self-contained use case, or (at the bare minimum) trim out
the irrelevant parts of your query and show us the schema for the tables in
question. Finally, please show the explain plans for the "good" and "bad"
runs you are experiencing. Thanks.
Cheers,
Greg
--
Crunchy Data - http
On Wed, Apr 3, 2019 at 12:13 PM Jonathan Marks
wrote:
Is there a way to tell Postgres “please don’t use index X when queries that
> could use index Y instead occur?”
>
Late to the party here, but...
Not directly. I've had luck in changing the procost of functions (or the
functions which back t
On Wed, Apr 17, 2019 at 11:16:28AM -0600, Michael Lewis wrote:
> > * Michael Lewis ([email protected]) wrote:
> > > Thanks for that advance warning since it is a handy option to force
> the
> > > planning barrier in my experience. What's a resource to see other
> coming
> > >
>
> > * Michael Lewis ([email protected]) wrote:
> > > Thanks for that advance warning since it is a handy option to force the
> > > planning barrier in my experience. What's a resource to see other
> coming
> > > changes in v12 especially changes to default behavior like this? Will
> there
> > >
On Wed, Apr 3, 2019 at 03:28:48PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Michael Lewis ([email protected]) wrote:
> > Thanks for that advance warning since it is a handy option to force the
> > planning barrier in my experience. What's a resource to see other coming
> > changes in v12 es
Greetings,
* Michael Lewis ([email protected]) wrote:
> Thanks for that advance warning since it is a handy option to force the
> planning barrier in my experience. What's a resource to see other coming
> changes in v12 especially changes to default behavior like this? Will there
> be a new cte_c
Thanks for that advance warning since it is a handy option to force the
planning barrier in my experience. What's a resource to see other coming
changes in v12 especially changes to default behavior like this? Will there
be a new cte_collapse_limit setting or similar?
Greetings,
* Michael Lewis ([email protected]) 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 th
>
> 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
11 matches
Mail list logo
