> 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