On May 28, 2004, at 1:51 AM, Branko Čibej wrote:
> BDB supports variable-length keys, but table-based databases (which we
> want to support in future) are notoriously cranky about rejecting
> such, and they're not very efficient in BDB, either. So the structure
> of the index would have look like this:
>
> (dir-id, name, [txn-id]) -> info
I'm not sure what you mean by cranky. I'm most familiar with
PosgreSQL. I believe most DBs support variable length text-type
fields. I know PosgreSQL does, and I'd be surprised if DB2, Oracle,
MySQL didn't. From the docs: "In addition, PostgreSQL provides the
'text' type, which stores strings of any length. Although the type
'text' is not in the SQL standard, several other SQL database
management systems have it as well." Such fields can be primary keys.
Given the quality of the query planner, I suggest not writing off
apparent encoding inefficiencies because you might find that backend
efficiencies more than make up for it. (There are also variable-length
binary types available, though I think there is more variation in them
between different SQL databases.)
PostgreSQL also supports multi-column indices, which can be efficiently
used according to this rule: "The query planner can use a multicolumn
index for queries that involve the leftmost column in the index
definition plus any number of columns listed to the right of it,
without a gap." I mention it because it looks like that might be
particularly useful given your tuple there with an optional third
member.
I know this doesn't have any immediate impact as there is no SQL db
backend. I'm just trying to follow along and was surprised by your
comment.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 28 17:06:14 2004