Re: performance question
От | Tom Lane |
---|---|
Тема | Re: performance question |
Дата | |
Msg-id | 7168.1040671596@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | performance question ("Devinder K Rajput" <Devinder.Rajput@ipaper.com>) |
Список | pgsql-novice |
"Devinder K Rajput" <Devinder.Rajput@ipaper.com> writes: > I am running a query and getting the following output in the log: > 2002-12-23 10:25:20 DEBUG: ProcessQuery > 2002-12-23 10:25:20 DEBUG: CommitTransactionCommand > 2002-12-23 10:25:20 DEBUG: StartTransactionCommand > 2002-12-23 10:25:20 DEBUG: query: fetch 1000 from my_cursor > 2002-12-23 10:25:20 DEBUG: ProcessUtility: fetch 1000 from my_cursor > 2002-12-23 10:30:10 DEBUG: proc_exit(0) > 2002-12-23 10:30:10 DEBUG: shmem_exit(0) > 2002-12-23 10:30:10 DEBUG: exit(0) > /usr/bin/postmaster: reaping dead processes... > /usr/bin/postmaster: CleanupProc: pid 16940 exited with status 0 > 2002-12-23 10:35:10 DEBUG: proc_exit(0) > 2002-12-23 10:35:10 DEBUG: shmem_exit(0) > 2002-12-23 10:35:10 DEBUG: exit(0) > /usr/bin/postmaster: reaping dead processes... > /usr/bin/postmaster: CleanupProc: pid 16947 exited with status 0 > 2002-12-23 10:40:10 DEBUG: proc_exit(0) > 2002-12-23 10:40:10 DEBUG: shmem_exit(0) > 2002-12-23 10:40:10 DEBUG: exit(0) > /usr/bin/postmaster: reaping dead processes... > /usr/bin/postmaster: CleanupProc: pid 16967 exited with status 0 > The last five lines repeat again and again exactly every five minutes. Presumably you've got a cron-driven task that connects to the database once every five minutes? Anyway, those entries just show server processes exiting normally. They've got nothing to do with your cursor query. > postmaster is using up to 90% of the CPU at times and is staying above 70% > for most of the time. When you haven't shown us the query that underlies the cursor, it's hard to say anything useful, but I'd wonder about unconstrained joins and similar mistakes. Or maybe you need to do some query optimization work. What is the query, and what does EXPLAIN show as its query plan? regards, tom lane
В списке pgsql-novice по дате отправления: