Lamar Owen wrote:
Good evening.
RPMs for PostgreSQL 7.3.4, built on three architectures, are in the midst of uploading to ftp.postgresql.org, in /pub/binary/v7.3.4/RPMS. As usual, inside that directory is the directory SRPMS, which contains the source RPM, as well as the three binary RPM directories I am uploading. One minor thing; a source RPM suitable for rebuilding on Red Hat 7.3 is available in the aurora-1.0 subdirectory. Aurora 1.0 is basically Red Hat 7.3 for SPARC; there are also SPARC binaries there.
Other than the version change, this RPMset includes the correct JDBC jars. There are a couple of fixes that have been e-mailed to me that are not in this update; I will address those as soon as I can.
In other news, I have changed jobs. Previously, I worked full-time as a broadcast engineer/IT person for WGCR Radio. I still work part-time for them, amongst other radio stations, but my full-time position is now as Director of Information Technology for Pisgah Astronomical Research Institute (PARI), a radio/optical astronomical observatory located in Western North Carolina. You can find out more about PARI at our website, www.pari.edu.
PARI is already using PostgreSQL for several applications, and soon will be looking at PostgreSQL for a large data warehousing application. And, in this case, I do mean large. I will be indexing and storing over three million astronomical photographic plates (if plans come together!), where each plate will scan in at roughly 650-750MB in size (uncompressed) (and this is 8-level grayscale scanning). Mass storage will be critical of this priceless data store, and PostgreSQL may very well fit the bill. I'm still in the planning phases, and we are still trying to secure funding for this project. But I am relatively confident that PostgreSQL will rise to the occassion. Some of the plates in question are over 100 years old.
New challenges, new opportunities. But still the same PostgreSQL.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
