Re: LIMIT clause slowing down query in some cases, accelerating in others

From: Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>
To: "Klaus P(dot) Pieper" <kpi6288(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: LIMIT clause slowing down query in some cases, accelerating in others
Date: 2017-04-28 08:16:33
Message-ID: 10b77ee9-582d-6e7e-260c-b1d8f06986a1@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 04/26/2017 08:11 PM, Klaus P. Pieper wrote:
>
> Running PostgreSQL 9.6 on a Windows Server.
>
> Table “t” is kind of a materialized view with > 100 columns and 2.24
> Mio rows. Queries are generated by an ORM framework – fairly difficult
> to modify.
>
> Vacuum analyze was carried out – no impact.
>
>
>
> The framework generates queries like this:
>
>
>
> select N0."uorderid" from "t" N0
>
> where (N0."szzip" like E'33%')
>
> order by N0."szzip" asc nulls last LIMIT 128 OFFSET 0
>

The planner has to choose whether to use an index for filtering or an
index for sorting. If you're always doing prefix searches like in your
two examples, then you want an index which can do both.

CREATE INDEX ON t (szzip text_pattern_ops, uorderid);

I invite you to read the documentation about text_pattern_ops at
https://www.postgresql.org/docs/current/static/indexes-opclass.html

--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom DalPozzo 2017-04-28 10:32:28 clarification about async streaming replication and replication slots
Previous Message Glen Huang 2017-04-28 04:24:01 json_agg doesn't generate the smallest json possible?