> I believe it would be best to largely separate the questions of storage and > access. Partly because of Florian's concern that you'd frequently want only > one representation of the whole graph, but also because the actual storage > interface does NOT have to be user friendly if we have a good access layer. > In particular, if rows had a low overhead, we'd probably just store graphs > that way. That's obviously not the case in PG, so is there some kind of > hybrid approach we could use? Perhaps sections of a graph could be stored > with one piece of MVCC overhead per section?
Yes, I agree. We can probably store some(persistent) data in a table,and the 'hot' parts of the datatype(like adjacency lists) could be stored locally in a data structure which allows fast and low overhead accesses and updates. I completely agree with separating storage and access layers. Supporting Florian's concern, I would also agree with your point of abstraction. Users should not concern themselves with backend storage details. > That's why I think separating access from storage is going to be very > important; if we do that up-front, we can change the storage latter as we > get real experience with this. +1. > Second, we should consider how much the access layer should build on WITH > RECURSIVE and the like. Being able to detect specific use patterns of > CTE/WITH RECURSIVE seems like it could add a lot of value; but I also worry > that it's way to magical to be practical. I thought of a frequent access patterns mining tool recently. We can store the recent accesses and apply a pattern mining algorithm on that dataset(I was thinking of FP Growth algorithm). But again, it has its own set of issues and is a project in itself. Regards, Atri -- Regards, Atri l'apprenant -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
