From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Vadim Mikheev <vadim(at)krs(dot)ru> |
Cc: | kar(at)webline(dot)dk, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Priorities for 6.6 |
Date: | 1999-06-07 03:48:43 |
Message-ID: | 199906070348.XAA23431@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Just because of ... heap_open()->RelationBuildDesc() does it.
> Maybe we could delay smgropen?
>
> But in any case note that big guys have shared catalog cache,
> and this is not because of they haven't good buffer pool -:)
> Keeping page in pool for just single row is not good.
>
> "Oracle itself accesses the data dictionary frequently during
> the parsing of SQL statements. This access is essential to the
> continuing operation of Oracle. See Chapter 8, "The Data Dictionary,"
> for more information on the data dictionary.
>
> ...
>
> Caching of the Data Dictionary for Fast Access
>
> Because Oracle constantly accesses the data dictionary during database
> operation to validate user access and to verify the state of objects,
> much of the data dictionary information is cached in the SGA. All
> information is stored in memory using the LRU (least recently
> used) algorithm. Information typically kept in the caches is that
> required for parsing."
I agree we need it. I just think we could use better fsync more, and
seeing how hard shared catalog cache may be, it may be good to get fsync
faster first.
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1999-06-07 04:11:48 | Re: [HACKERS] postgresql-v6.5beta2.tar.gz ... |
Previous Message | Vadim Mikheev | 1999-06-07 03:47:14 | Re: [HACKERS] Priorities for 6.6 |