On Tue, Nov 24, 2015 at 5:29 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Nov 23, 2015 at 8:45 PM, Peter Geoghegan <p...@heroku.com> wrote: >> Beyond that, CREATE INDEX and CLUSTER utility >> cases will also need to be parallelized without all this executor >> infrastructure. > > Or, alternatively, CREATE INDEX and CLUSTER could be refactored to use > the executor. This is might sound crazy, but maybe it's not. Perhaps > we could have the executor tree output correctly-formed index tuples > that get funneled into a new kind of DestReceiver that puts them into > the index. I don't know if that's a GOOD idea, but it's an idea.
Having CREATE INDEX use the executor seems like a useful idea for reasons unrelated to parallelism. 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. Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers