From: | "Uwe C(dot) Schroeder" <uwe(at)oss4u(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | How many views... |
Date: | 2004-11-29 02:41:50 |
Message-ID: | 200411281841.50736.uwe@oss4u.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
a (maybe/probably) stupid idea just popped to my mind:
Problem:
I need to search a lot of locations based on distance (simple zipcode match
based on longitude and latitude). However I need to calculate the distance
between each of the nodes, so if you are in xxx I need to get the distance to
all others in the database. I'm currently doing this with a stored procedure
that gets the originating zipcode and a maximum distance in miles which then
selects all other nodes within that search radius. This is pretty unhandy,
but it works.
The idea:
I could create a view for every node in the system which calculates the
distance in the result set, making it easy to handle for the application:
select * from <view> where distance <= 50
The problem is, that the data will possibly contain thousands of nodes. I'd
also need 2 or 3 views per node - which could lead to 50.000 or even 100.000
views.
The question:
1) does it make sense to do this performance-wise?
2) does this make sense at all?
3) can postgresql handle that many views?
Thanks for any opinions (or better ideas than a stored proc or the views
concept)
UC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFBqoxujqGXBvRToM4RAusrAJ9e/7jljmE+wNVkeltvErxffCa+xACfba0X
b5ClK8BKCdg5cWaWCnqQklE=
=iiDR
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-11-29 02:44:11 | Re: sequencing two tables |
Previous Message | Christopher Browne | 2004-11-29 01:24:25 | Re: PGSQL: The Gateway will be kept. |