Re: Much Ado About COUNT(*)
От | Jonah H. Harris |
---|---|
Тема | Re: Much Ado About COUNT(*) |
Дата | |
Msg-id | 41E59D76.3090109@tvi.edu обсуждение исходный текст |
Ответ на | Re: Much Ado About COUNT(*) (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Much Ado About COUNT(*)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: