På lørdag 19. mars 2016 kl. 03:44:55, skrev Jeff Janes <jeff.ja...@gmail.com <mailto:jeff.ja...@gmail.com>>: On Wed, Mar 16, 2016 at 6:53 AM, Andreas Joseph Krogh <andr...@visena.com <mailto:andr...@visena.com>> wrote: På onsdag 16. mars 2016 kl. 14:37:27, skrev Tom Lane <t...@sss.pgh.pa.us <mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh <andr...@visena.com <mailto:andr...@visena.com>> writes: > 1. Why isnt' folder_id part of the index-cond?
Because a GIN index is useless for sorting. > 2. Is there a way to make it use the (same) index to sort by > received_timestamp? No. > 3. Using a GIN-index, is there a way to use the index at all for sorting? No. > 4. It doesn't seem like ts_rank uses the index for sorting either. Same reason. regards, tom lane So it's basically impossible to use FTS/GIN with sorting on large datasets? Are there any plans to improve this situation? I don't see why it would not be possible to create a new execution node type that does an index scan to obtain order (or just to satisfy an equality or range expression), and takes a bitmap (as produced by the FTS/GIN) to apply as a filter. But, I don't know of anyone planning on doing that. Isn't this what Postgres Pro are planning? http://postgrespro.com/roadmap/mssearch "Unlike external special-purpose search engines, a full-text search engine built in a DBMS is capable of combining full-text and attributive search criteria in SQL query syntax. It is planned to improve the existing PostgreSQL full-text search engine byextending the functionality of Generalized Inverted Index (GIN) to make it capable of storing extra information required for ranging query results. This search acceleration will allow to go back from external full-text search engines, thus facilitating system administration and use, reducing technology risks, and improving information security." -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>
