From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-20 05:25:26 |
Message-ID: | NDBBIJLOILGIKBGDINDFIEEHCFAA.Inoue@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> >> Unfortunately there is no index on pg_index's indrelid column in 7.0,
> >> so this is not fixable without an initdb. TODO item for 7.1, I guess.
>
> I've also been thinking about ways to implement the relcache-based
> caching of index information that I mentioned before. That doesn't
> address the scanning problem in general but it should improve
> performance for this part of the planner quite a bit.
Sounds reasonble to me.
> The trick is to
> ensure that other backends update their cached info whenever an index
> is added or deleted. I thought of one way to do that: force an update
> of the owning relation's pg_class tuple during CREATE or DROP INDEX,
> even when we don't have any actual change to make in its contents ---
> that'd force a relcache invalidate cycle at other backends. (Maybe
> we don't even need to change the pg_class tuple, but just send out a
> shared-cache-invalidate message as if we had.)
>
Seems CREATE INDEX already sends shared_cache_invalidate
message. DROP INDEX doesn't ?? I'm not sure.
> > I know another case. pg_attrdef has no index on (adrelid,attnum)
> > though it has an index on (adrelid).
>
> Doesn't look to me like we need an index on (adrelid,attnum), at
> least not in any paths that are common enough to justify maintaining
> another index. The (adrelid) index supports loading attrdef data
> into the relcache, which is the only path I'm particularly concerned
> about performance of...
>
It seems to me that an index on (adrelid,adnum) should
exist instead of the current index. It identifies pg_attrdef.
I say *Oops* about it in my trial implementation of ALTER
TABLE DROP COLUMN.
Regards.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-20 05:30:08 | Re: Performance (was: The New Slashdot Setup (includes MySql server)) |
Previous Message | Hiroshi Inoue | 2000-05-20 05:25:23 | RE: Performance (was: The New Slashdot Setup (includes MySql server)) |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-20 05:30:08 | Re: Performance (was: The New Slashdot Setup (includes MySql server)) |
Previous Message | Hiroshi Inoue | 2000-05-20 05:25:23 | RE: Performance (was: The New Slashdot Setup (includes MySql server)) |