From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Rouillard <rouilj(at)renesys(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Assessing performance of fetches |
Date: | 2011-04-18 19:41:19 |
Message-ID: | 15055.1303155679@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
John Rouillard <rouilj(at)renesys(dot)com> writes:
> I am seeing:
> 2011-04-16 00:55:33 UTC user(at)database(3516): LOG: duration:
> 371954.811 ms statement: FETCH FORWARD 1 FROM c_2aaaaaaeea50_a08
> While I obviously have a problem here, is there any way to log the
> actual select associated with the cursor other than logging all
> statements?
Can't think of one :-(
> Also once I have the select statement, does the fact that is is
> associated with a fetch/cursor change the steps I should take in
> tuning it compared to somebody just issuing a normal select?
The planner does treat cursor queries a bit different from plain
queries, putting more emphasis on getting the first rows sooner.
If you want to be sure you're getting the truth about what's happening,
try
EXPLAIN [ANALYZE] DECLARE c CURSOR FOR SELECT ...
rather than just
EXPLAIN [ANALYZE] SELECT ...
Other than that, it's the same as tuning a regular query.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pierre C | 2011-04-18 21:21:56 | Re: Background fsck |
Previous Message | Robert Haas | 2011-04-18 18:27:27 | Re: Select in subselect vs select = any array |