Simon Riggs wrote:
>Jonah,
>
>People's objections are:
>- this shouldn't be the system default, so would need to be implemented
>as a non-default option on a b-tree index
>- its a lot of code and if you want it, you gotta do it
>
>Remember you'll need to
>- agree all changes via the list and accept that redesigns may be
>required, even at a late stage of coding
>- write visibility code into the index
>- write an additional node type to handle the new capability
>- microarchitecture performance testing so you know whether its really
>worthwhile, covering a range of cases
>- add code to the optimiser to so it can estimate the cost of using this
>and to know when to do this
>- add a column to the catalog to record whether an index has the
>visibility option
>- add code to the parser to invoke the option
>- update pg_dump so that it correctly dumps tables with that option
>- copy and adapt all of the existing tests for the new mechanism
>- document it
>
>If you really want to do all of that, I'm sure you'd get help, but
>mostly it will be you that has to drive the change through.
>
>There are some other benefits of that implementation:
>You'd be able to vacuum the index (only), allowing index access to
>remain reasonably constant, even as the table itself grew from dead
>rows.
>
>The index could then make sensible the reasonably common practice of
>using a covered index - i.e. putting additional columns into the index
>to satisfy the whole query just from the index.
>
>
>
Simon,
I am willing to take it on and I understand that the workload is mine.
As long as everyone gives me some suggestions, I'm good it being optional.
-Jonah