VLSI design data in PostgreSQL? - Mailing list pgsql-general

From Andrew P. Lentvorski
Subject VLSI design data in PostgreSQL?
Date
Msg-id 20020915182559.K93626-100000@mail.allcaps.org
Whole thread Raw
List pgsql-general
I noticed on a quick scan through the archives that there is not one
mention of using PostgreSQL for VLSI design data.

The reason I bring this up is that I have been writing what is effectively
a polygon editor for VLSI applications.  Given the number of graphical
objects (millions to billions), I had to implement an RTree data structure
in source code to keep performance sufficiently high.

While I created an RTree data structure from scratch, it strikes me as a
patently absurd thing to do when there are people devloping PostgreSQL who
do this with far more insight than I will ever have.

As VLSI design data seems to get researched along with GIS spatial data, I
took a cursory look at PostGIS to see what is there.  The first problem
out the shoot is that its license is not BSD.  However, a more technical
problem is line sweep algorithms.

VLSI designs need to be checked for topological compliance.
Consequently, there are a *lot* of rules specifing spacings, overlaps,
tolerances, etc.  Commercial tools which do this kind of stuff (Dracula or
Assura from Cadence, Calibre from Mentor, etc) generally have their own
data structures to handle the algorithmic and data complexity with line
sweep algorithms.  Not being a database guru, I don't understand how
PostgreSQL holding my data would affect the speed of these kinds of
algorithms, and I didn't see any references from the GIS folks about
tolerancing-type checks.

The response I'm kind of looking for is "GIS folks do tolerancing, too.
Here are some references on performance." or "GIS folks don't do
tolerancing checks like that, performance will be poor".

Even better would be to have a response from someone who is actually using
PostgreSQL for VLSI design data.

Sorry to be so vague, but I'm not a database guru, so I don't quite know
the right questions to ask.

Thanks,
-a



pgsql-general by date:

Previous
From: Neil Conway
Date:
Subject: Re: Real time process monitor in Postgres
Next
From: Bruce Momjian
Date:
Subject: Re: Looking for more "big name" places that use PostgreSQL