Re: [HACKERS] Priorities for 6.6

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

In response to

Browse pgsql-hackers by date

  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