[HN Gopher] Deconstructing the Postgres planner to find indexing...
       ___________________________________________________________________
        
       Deconstructing the Postgres planner to find indexing opportunities
        
       Author : Tomte
       Score  : 36 points
       Date   : 2021-11-03 07:23 UTC (1 days ago)
        
 (HTM) web link (pganalyze.com)
 (TXT) w3m dump (pganalyze.com)
        
       | jerrysievert wrote:
       | I used to do this the "old fashioned" way:
       | 
       | * log the queries from the application
       | 
       | * parse the queries into an AST
       | 
       | * collate the ASTs to form the most common query patterns
       | 
       | * cross-reference existing indexes
       | 
       | * create index recommendations with and without predicates
       | 
       | that worked pretty well, up until you're trying to decide which
       | index type is going to be best.
       | 
       | this is pretty darned neat in comparison. I do hope they open-
       | source it like they did pg_query.
        
         | lfittl wrote:
         | (author here)
         | 
         | Nice approach! The latter part of that workflow is where we are
         | focused now, i.e. now that we can plan and recommend B-tree
         | indexes for individual queries, how do we utilize this to
         | recommend a set of indexes for a whole database (taking into
         | account different predicate variations).
         | 
         | On open-sourcing this code: Not at this moment - we do however
         | offer a WASM build of this logic for free use at
         | https://pganalyze.com/index-advisor
        
       ___________________________________________________________________
       (page generated 2021-11-04 23:00 UTC)