Re: what's the slowest part in the SQL

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Suya Huang <shuang(at)connexity(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: what's the slowest part in the SQL
Date: 2016-08-16 13:56:01
Message-ID: CAHyXU0xMAemLvZ5Y_1V+_xBYSypNE968h4r+MFfgFQhpamg_FQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Aug 9, 2016 at 6:27 PM, Suya Huang <shuang(at)connexity(dot)com> wrote:
> Hi,
> I’ve got a SQL runs for about 4 seconds first time it’s been executed,but
> very fast (20ms) for the consequent runs. I thought it’s because that the
> first time table being loaded into memory. However, if you change the where
> clause value from “cat” to “dog”, it runs about 4 seconds as it’s never been
> executed before. Therefore, it doesn’t sound like the reason of table not
> being cached.

LIMIT clause operations combined with random access are particularly
sensitive to caching on slow media. The exact pages you want are
scattered around the dist but repeated scans of the same values will
pull up exactly the ones you want. You can warm the table assuming
your memory is sufficient enough to cache all the data you need.
Another (I think better-) plan is to buy media with faster random
access.

Are you using pg_trgm to index the 'name' field? gist/gin indexes are
*very* dependent on caching/fast drives as the indexes tend to be fat.

merlin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message pinker 2016-08-17 11:45:03 Big data INSERT optimization - ExclusiveLock on extension of the table
Previous Message Claudio Freire 2016-08-15 17:42:03 Re: index fragmentation on insert-only table with non-unique column