[PERFORM] Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1

Hello, We are using PostgreSQL 9.0.3, compiled by Visual C++ build 1500, 32-bit, installed on Windows 2003 R2 32-bit. We have an 'aisposition' table used for a GPS tracking application, containing ~30 million rows and a number of indexes. Two of these are: idx_receiveddatetime:

Re: [PERFORM] Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1

The row estimate is way off. Is autovacuum disabled? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1

John Surcombe john.surco...@digimap.gg writes: When we 'EXPLAIN' this query, PostgreSQL says it is using the index idx_receiveddatetime. The way the application is designed means that in virtually all cases the query will have to scan a very long way into idx_receiveddatetime to find the

Re: [PERFORM] Tuning massive UPDATES and GROUP BY's?

Don't insert data into an indexed table. A very important point with bulk-loading is that you should load all the data first, then create the indexes. Running multiple (different) CREATE INDEX queries in parallel can additionally save a lot of time. Also don't move data back and forth between

Re: [PERFORM] Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1

I wrote: John Surcombe john.surco...@digimap.gg writes: When we 'EXPLAIN' this query, PostgreSQL says it is using the index idx_receiveddatetime. The way the application is designed means that in virtually all cases the query will have to scan a very long way into idx_receiveddatetime to