Re: [GENERAL] Storing computed values

2008-04-21 Thread Colin Wetherbee
Richard Broersma wrote: On Mon, Apr 21, 2008 at 12:24 PM, Colin Wetherbee <[EMAIL PROTECTED]> wrote: Right, but the problem I see is that my locations are not actually stored in foo. Since many rows of foo can reference the same location, the locations are stored in a separate table and, in fa

Re: [GENERAL] Storing computed values

2008-04-21 Thread Richard Broersma
On Mon, Apr 21, 2008 at 12:24 PM, Colin Wetherbee <[EMAIL PROTECTED]> wrote: > Right, but the problem I see is that my locations are not actually stored in > foo. Since many rows of foo can reference the same location, the locations > are stored in a separate table and, in fact, are referenced by

Re: [GENERAL] Storing computed values

2008-04-21 Thread Colin Wetherbee
Richard Broersma wrote: On Mon, Apr 21, 2008 at 11:19 AM, Colin Wetherbee <[EMAIL PROTECTED]> wrote: My impression of functional indexes is that they're useful mostly in WHERE queries, like the following. SELECT foo, bar, baz FROM some_table WHERE lower(foo) = 'qux'; In this case, the index w

Re: [GENERAL] Storing computed values

2008-04-21 Thread Colin Wetherbee
Colin Wetherbee wrote: Richard Broersma wrote: On Mon, Apr 21, 2008 at 11:02 AM, Colin Wetherbee <[EMAIL PROTECTED]> wrote: Let's say my points table looks like this: point_id | location -+-- 1 | 0101... <-- some PostGIS geometry string 2 | 0101...

Re: [GENERAL] Storing computed values

2008-04-21 Thread Richard Broersma
On Mon, Apr 21, 2008 at 11:19 AM, Colin Wetherbee <[EMAIL PROTECTED]> wrote: > My impression of functional indexes is that they're useful mostly in WHERE > queries, like the following. > > SELECT foo, bar, baz FROM some_table WHERE lower(foo) = 'qux'; > > In this case, the index would be created o

Re: [GENERAL] Storing computed values

2008-04-21 Thread Colin Wetherbee
Richard Broersma wrote: On Mon, Apr 21, 2008 at 11:02 AM, Colin Wetherbee <[EMAIL PROTECTED]> wrote: Let's say my points table looks like this: point_id | location -+-- 1 | 0101... <-- some PostGIS geometry string 2 | 0101... And, my foo table, whic

Re: [GENERAL] Storing computed values

2008-04-21 Thread Richard Broersma
On Mon, Apr 21, 2008 at 11:02 AM, Colin Wetherbee <[EMAIL PROTECTED]> wrote: > Let's say my points table looks like this: > > point_id | location > -+-- > 1 | 0101... <-- some PostGIS geometry string > 2 | 0101... > > And, my foo table, which contains da

Re: [GENERAL] Storing computed values

2008-04-21 Thread Colin Wetherbee
Colin Wetherbee wrote: SELECT connect(p_start.location, p_end.location) FROM foo JOIN points AS p_start ON foo.point_id_start = points.point_id JOIN points AS p_end ON foo.point_id_end = points.point_id WHERE foo.id = 8192; As I didn't test this code, my syntax was slightly incorrect. JOIN

Re: [GENERAL] Storing computed values

2008-04-21 Thread Colin Wetherbee
Richard Broersma wrote: On Mon, Apr 21, 2008 at 10:34 AM, Colin Wetherbee <[EMAIL PROTECTED]> wrote: I would like to have a table that contains a connection for each distinct pair of points (point1 to point2 is the same as point2 to point1). This table would then be automatically updated every

Re: [GENERAL] Storing computed values

2008-04-21 Thread Richard Broersma
On Mon, Apr 21, 2008 at 10:34 AM, Colin Wetherbee <[EMAIL PROTECTED]> wrote: > I would like to have a table that contains a connection for each distinct > pair of points (point1 to point2 is the same as point2 to point1). This > table would then be automatically updated every time a modification

[GENERAL] Storing computed values

2008-04-21 Thread Colin Wetherbee
Greetings. I have a question regarding storing computed values. Essentially, it's a question about caching, and I'm willing to implement a cache on the client side or using pg_memcache, but I wonder if I can do this in a PostgreSQL table, instead? The background is that I'm using PostGIS to