Re: Performance (was: The New Slashdot Setup (includes MySql server))

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Michael A(dot) Olson" <mao(at)sleepycat(dot)com>, "Matthias Urlichs" <smurf(at)noris(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Performance (was: The New Slashdot Setup (includes MySql server))
Date: 2000-05-21 18:45:22
Message-ID: 10090.958934722@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> Isn't it a fundamental principle to define primary(unique
> identification) constraint for each table ?
> I had never thought that the only one index of pg_attrdef
> isn't an unique identification index until I came across the
> unexpcted result of my DROP COLUMN test case.

Good point --- I was only thinking about the performance aspect, but
if we're going to have unique indexes to prevent errors in other
system tables then pg_attrdef deserves one too.

Actually, I have a more radical proposal: why not get rid of pg_attrdef
entirely, and add its two useful columns (adsrc, adbin) to pg_attribute?
If we allow them to be NULL for attributes with no default, then there's
no space overhead where they're not being used, and we eliminate any
need for the second table.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Matthias Urlichs 2000-05-21 20:37:21 Re: MySQL's "crashme" (was Re: Performance)
Previous Message Tom Lane 2000-05-21 18:03:57 Re: fmgr_info error

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2000-05-21 18:50:48 Re: Thus spoke SQL3 (on OO)
Previous Message Hannu Krosing 2000-05-21 18:42:03 Re: Thus spoke SQL3 (on OO)