Tim Perdue writes:
> the 8K tuple limit.
BLCKSZ in src/include/config.h -- But it's being worked on these very
> Postgres never saturated all 4 processors as MySQL did.
Blame that on your operating system?
> MySQL has some nice admin tools that allow you to watch individual
> connections and queries as they progress
tail -f <serverlog>
> and tools to recover from corruption. I haven't seem any similar tools
> for postgres.
I always like this one -- "tools to recover from corruption". If your
database is truly corrupted then there's nothing you can do about it, you
need a backup. If your database engine just creates garbage once in a
while then the solution is to fix the database engine, not to provide
external tools to clean up after it.
> as there are no known tools to fix index
> Both databases use a similar command-line interface. Postgres uses
> "slash commands" to help you view database structures. MySQL uses a more
> memorable, uniform syntax like "Show Tables; Show Databases; Describe
Yeah, but once you have memorized ours then it will be shorter to type. :)
And you get tab completion. And what's so non-uniform about ours?
> The "transaction" support that MySQL lacks is included in Postgres,
> although you'll never miss it on a website,
Think again. Transactions and multi-version concurrency control are
essential for any multi-user web site that expects any writes at all. I'll
reiterate the old Bugzilla bug: User A issues a search that "takes
forever". User B wants to update some information in the database, waits
for user A. Now *every* user in the system, reading or writing, is blocked
waiting for A (and B).
But you don't even have to go that far. What if you just update two
separate tables at once?
If your web site is truly read only, yes, you don't need transactions. But
then you don't need a database either. If your web site does writes, you
need transactions, or you're really not trying hard enough.
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2000-07-05 00:25:53|
|Subject: Re: Memory-context slinging |
|Previous:||From: Peter Eisentraut||Date: 2000-07-05 00:12:35|
|Subject: Repair plan for inet and cidr types|