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
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 |