Jan Wieck wrote:
> mlw wrote:
> >
> > The U.S. Census provides a database of street polygons and other data
> > about landmarks, elevation, etc. This was discussed in a separate thread.
> >
> > The main URL is here:
> > http://www.census.gov/geo/www/tiger/index.html
>
> While yes, the tiger database (or better it's content) is interesting, I
> don't think that it can be counted as a "complex database". Just that
> something is big doesn't mean that.
Just so.
There are doubtless interesting cases that may be tested by virtue of
having a data set that is large, and perhaps "deeply interlinked."
But that only covers cases that have to do with "largeness." It doesn't
help ensure that PostgreSQL plays well when it gets hit by nested sets
of updates where the challenges involve ensuring the system performs OK
and does not deadlock when hit by complex sets of transactions.
So that an "interesting" database might involve not only a database, but
also a set of transactions that hit multiple tables that are to update
that database. In effect, something like the "readers/writers" that get
used to test locking semantics.
This is something that would not be able to solely consist of a set of
tables; it would have to include streams of updates. Something like one
of the TPC benchmarks...
--
output = reverse("moc.enworbbc@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/rdbms.html
"If I could find a way to get [Saddam Hussein] out of there, even
putting a contract out on him, if the CIA still did that sort of a
thing, assuming it ever did, I would be for it." -- Richard M. Nixon