On Sat, Feb 23, 2019 at 9:24 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Every time this has come up, I've opined that the right fix is to jack > up the List API and drive a new implementation underneath, as we did > once before (cf commit d0b4399d81). I thought maybe it was about time > to provide some evidence for that position, so attached is a POC patch > that changes Lists into expansible arrays, while preserving most of > their existing API.
I'm not really convinced that this is the way to go. The thing is, any third-party code people have that uses a List may simply break. If you kept the existing List and changed a bunch of existing code to use a new Vector implementation, or Thomas's SimpleVector stuff, then that wouldn't happen. The reason why people - or at least me - have been reluctant to accept that you can just jack up the API and drive a new implementation underneath is that the new implementation will involve breaking guarantees on which existing code relies; indeed, your email makes it pretty clear that this is the case. If you could replace the existing implementation without breaking any code, that would be a no-brainer but there's no real way to do that and get the performance benefits you're seeking to obtain. It is also perhaps worth mentioning that reimplementing a List as an array means that it is... not a list. That is a pretty odd state of affairs, and to me is another sign that we want to leave the existing thing alone and convert some/most/all core code to use a new thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
