| 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: | Whole Thread | Raw Message | 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 |