Re: AW: pg_attribute growing and growing and growing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: pg_attribute growing and growing and growing
Date: 2000-08-21 14:23:37
Message-ID: 1618.966867817@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
>> Since table OIDs keep increasing, this formulation ensures that new
>> entries will always sort to the end of the index, and so space freed
>> internally in the indexes can never get re-used. Swapping the column
>> order may eliminate that problem --- but I'm not sure what if any
>> speed penalty would be incurred. Thoughts anyone?

> Isn't pg_attribute often accessed with a "where oid=xxx" restriction
> to get all cols for a given table ?

Hmm, good point. I don't think the system itself does that --- AFAIR
it just looks up specific rows by relid+name or relid+num --- but making
this change would make the indexes useless for applications that make
that kind of query.

Oh well, back to the drawing board...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Don Baccus 2000-08-21 14:35:10 Re: Bug tracking (was Re: +/- Inf for float8's)
Previous Message Don Baccus 2000-08-21 14:14:38 Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan