Re: PG process architecture
От | Tom Lane |
---|---|
Тема | Re: PG process architecture |
Дата | |
Msg-id | 12945.1136993844@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | PG process architecture ("Milen Kulev" <makulev@gmx.net>) |
Список | pgsql-hackers |
"Milen Kulev" <makulev@gmx.net> writes: > My questions is: > Where PG is storing data dictionary information (coming form system pg_* > tables) while parsing the queries ? There's a limited-size "catalog cache" in each backend process, which might be the closest analogy to this. Offhand I think it's fixed at 5000 rows --- there's no user-visible knob to control it, anyway. > I suppose each each background process is parsing (and eventually caching) > the parsed SQL > statements in his own memory (within each backend process), There is no such cache. If you tell us to PREPARE something, we save the plan, otherwise not. > If I have a system with 50 or 100 connection (and the corresponding 100 > backend processes), > and one session creates an index on a given table, how do the other 99 > processes > notice that they can use (or at least estimate the appropriatness of the > usage of) the new index ? There's a cache-invalidation signaling mechanism for the catcache, which is what drives this sort of thing. regards, tom lane
В списке pgsql-hackers по дате отправления: