| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
| Cc: | Jim Nasby <jim(at)nasby(dot)net>, Misa Simic <misa(dot)simic(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Graph datatype addition |
| Date: | 2013-05-09 13:36:59 |
| Message-ID: | CAHyXU0yMs_9qr63mA=39h=4TpaUt0zHmYYwKSUzUi2iXt1ZZOA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 8, 2013 at 2:16 PM, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> wrote:
>>
>> Your second drawing didn't really make any sense to me. :(
>>
>> I do think it would be most productive to focus on what the API for dealing
>> with graph data would look like before trying to handle the storage aspect.
>> The storage is potentially dirt-simple, as others have shown. The only
>> challenge would be efficiency, but it's impossible to discuss efficiency
>> without some clue of how the data will be accessed. Frankly, for the first
>> round of this I think it would be best if the storage really was just some
>> raw tables. Once something is available people will start figuring out how
>> to use it, and where the API needs to be improved.
>>
>> --
>
> Thanks for your reply.
>
> Yes,my drawing sucks.heh.
>
> Ok,I agree. I was pretty perked up about efficiency in storage, hence
> started designing.
This is the wrong place to start. A proposed API will help people
understand the use cases you're trying to solve (if any) that are
insufficiently covered by existing paradigms.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2013-05-09 14:09:39 | Re: improving PL/Python builds on OS X |
| Previous Message | Amit Kapila | 2013-05-09 13:08:36 | Re: Fast promotion failure |