On 5.9.2013 09:36, Atri Sharma wrote: > On Thu, Sep 5, 2013 at 10:59 AM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: >> Satoshi Nagayasu wrote: >> >>> But, for now, I think we should have a real index for the >>> statistics data because we already have several index storages, >>> and it will allow us to minimize read/write operations. >>> >>> BTW, what kind of index would be preferred for this purpose? >>> btree or hash? >> >> I find it hard to get excited about using the AM interface for >> this purpose. To me it makes a lot more sense to have separate, >> much simpler code. We don't need any transactionality, user >> defined types, user defined operators, or anything like that. > > +1. > > But, would not rewriting a lot of existing functionalities > potentially lead to points of contention and/or much more effort?
Don't forget the stats are written only by the postmaster, all the regular backends only read it (and eventually send updates back). But yes, contention might be a problem, because there will have to be some kind of locking that is not needed now when the postmaster is writing fresh copy into a new file. But I think we need to implement something and then measure this. Because it might even with the contention the overall performance might actually improve. I'd vote to try a simple approach first - adding some simple array 'index' allowing fast access to particular records etc. At least that was my plan. But feel free to implement something more advanced (e.g. a BTree storage) and we can compare the results. Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
