## Re: Odd Sort/Limit/Max Problem

From: Stephan Szabo Josh Berkus Re: Odd Sort/Limit/Max Problem 2002-12-13 20:10:20 20021213120738.D25935-100000@megazone23.bigpanda.com (view raw, whole thread or download thread mbox) 2002-12-13 19:55:51 from Josh Berkus  2002-12-13 20:10:20 from Stephan Szabo  2002-12-13 20:24:23 from Tom Lane   2002-12-13 22:22:08 from Hannu Krosing    2002-12-14 00:03:55 from Tom Lane pgsql-performance
```On Fri, 13 Dec 2002, Josh Berkus wrote:

> First, as expected, a regular aggregate is slow:

> So we use the workaround standard for PostgreSQL:
>
> ... which is fast, but returns NULL, since nulls sort to the bottom!  So we
>
> jwnet=> explain analyze select date_resolved from case_clients where
> date_resolved is not null order by date_resolved desc limit 1;
> NOTICE:  QUERY PLAN:
>
> Limit  (cost=0.00..4.06 rows=1 width=4) (actual time=219.63..219.64 rows=1
> loops=1)
>   ->  Index Scan Backward using idx_caseclients_resolved on case_clients
> (cost=0.00..163420.59 rows=40272 width=4) (actual time=219.62..219.62 rows=2
> loops=1)
> Total runtime: 219.76 msec
>
> Aieee!  Almost as slow as the aggregate!

I'd suggest trying a partial index on date_resolved where date_resolve is
not null.  In my simple tests on about 200,000 rows of ints where 50% are
null that sort of index cut the runtime on my machine from 407.66 msec to
0.15 msec.

```

### pgsql-performance by date

 Next: From: Tom Lane Date: 2002-12-13 20:24:23 Subject: Re: Odd Sort/Limit/Max Problem Previous: From: Josh Berkus Date: 2002-12-13 19:55:51 Subject: Odd Sort/Limit/Max Problem