Re: EXPLAIN ANALYZE

Поиск
Список
Период
Сортировка
От Joshua Reich
Тема Re: EXPLAIN ANALYZE
Дата
Msg-id 4580597D.6060801@root.net
обсуждение исходный текст
Ответ на Re: EXPLAIN ANALYZE  ("Jim C. Nasby" <jim@nasby.net>)
Список pgsql-hackers
Thumbs up on this from a lurker.

I recall a previous post about some sort of "progress bar" hack that 
would show you where in a plan a currently executing query was at. Has 
any work been done on this?

Josh Reich


Jim C. Nasby wrote:
> On Mon, Dec 11, 2006 at 12:24:12AM +0100, Peter Eisentraut wrote:
>   
>> Simon Riggs wrote:
>>     
>>> Well, I'd like a way of making EXPLAIN ANALYZE return something
>>> useful within a reasonable amount of time. We can define that as the
>>> amount of time that the user considers is their goal for the query.
>>>       
>> What sort of "useful" results would you expect to be able to see from 
>> such an aborted EXPLAIN ANALYZE?  I cannot quite imagine what 
>> instructive value a partially executed plan output would have.  It's 
>> not like we can somehow ensure executing an equal proportion of each 
>> plan node or something.  Do you have a specific case in mind?
>>     
>
> The query is most likely to get canceled while it is working on whatever
> node in the plan is the bottleneck, and it's likely going to be easy to
> spot since nodes above it wouldn't have gotten much done.
>   



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Simon Riggs"
Дата:
Сообщение: Re: Concurrent connections in psql
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Vacuum, analyze, and setting reltuples of pg_class