From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallelism and sorting |
Date: | 2015-11-25 01:02:58 |
Message-ID: | 565508C2.9020403@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/24/15 7:10 AM, Ants Aasma wrote:
> The use case I have in mind is a table containing multiple years worth
> of (approximately) time series data, where overwhelming majority of
> queries are explicitly interested in recent data. Having a partial
> index with WHERE tstamp > $some_recent_tstamp cutting out 90+% of
> tuples was extremely helpful for performance for both index size
> reasons and having to process less tuples. This index needs to be
> periodically rebuilt with a newer timestamp constant, and the rebuild
> would be a lot faster if it could use the existing index to perform an
> index only scan of 10% of data instead of scanning and sorting the
> full table.
There are other cases where you'd want to build an index off an existing
index as well. It's not that uncommon to have small, specialized indexes
that are fully or partially a subset of another index.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-11-25 01:12:35 | Re: [PROPOSAL] VACUUM Progress Checker. |
Previous Message | Amit Langote | 2015-11-25 01:02:22 | Re: [PROPOSAL] VACUUM Progress Checker. |