Re: Tuning a query with ORDER BY and LIMIT - Mailing list pgsql-general

From Jeff Janes
Subject Re: Tuning a query with ORDER BY and LIMIT
Date
Msg-id CAMkU=1yFeiVSP+XbLRxso46xxHGVaC1NiT7pNVWuig=H__ktbA@mail.gmail.com
Whole thread Raw
In response to Tuning a query with ORDER BY and LIMIT  ("Dirschel, Steve" <steve.dirschel@thomsonreuters.com>)
List pgsql-general
On Wed, Jun 22, 2022 at 3:39 PM Dirschel, Steve <steve.dirschel@thomsonreuters.com> wrote:
 

explain (analyze, verbose, costs, buffers, timing, summary, hashes)


'hashes', what's that?  Are you using community PostgreSQL, or someones fork?
 

With Oracle for a query like this since the index is on the 3 columns matching the WHERE clause and the ORDER BY clause is in the 4th position Oracle would be able to scan that index and as soon as it finds the first matching 50 rows. 


Can you show the plan from Oracle?  I'm not an expert at reading their plans, but certainly they are easier to attempt to read if you can at least see them.
 

I was questioning if the result IN clause was causing the issue so I ran the query with result = and see the same results:


I can't reproduce this at all.  With simple equality it absolutely uses the index for ordering in that case, even in v10.

Cheers,

Jeff

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERROR: new collation (en_US.UTF-8) is incompatible with the collation of the template database (en_US.utf-8)
Next
From: Jeff Janes
Date:
Subject: Re: Tuning a query with ORDER BY and LIMIT