Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
Дата
Msg-id CAFj8pRD2bJWPWyGCqzza77P7Nz5bd1vXGSrFZ7XSL=SFcj8QVQ@mail.gmail.com
обсуждение исходный текст
Ответ на RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.  (<slapo@centrum.sk>)
Список pgsql-performance
2013/8/7  <slapo@centrum.sk>:
> You're right, it does... but it's quite odd, because I re-ran the
> explain-analyze statement and got the same results.
>
> Still, the query now runs for about a second as mentioned before, so it's
> almost like something's missing from the explain, but I'm certain I copied
> it all.

what is time of EXPLAIN only ?

Pavel

>
>
>
> I did this via pgadmin, but that shouldn't matter, should it?
>
>
>
> Thank you,
>
>
>
> Peter Slapansky
>
> ______________________________________________________________
>> Od: Igor Neyman <ineyman@perceptron.com>
>> Komu: "slapo@centrum.sk" <slapo@centrum.sk>, Pavel Stehule
>> <pavel.stehule@gmail.com>
>> Dátum: 07.08.2013 15:47
>> Predmet: RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated
>> query on a view with another view inside of it.
>>
>
>> CC: "pgsql-performance@postgresql.org"
>
> Your last explain analyze (with 3 settings set to 32)  shows query duration
> 10ms, not 1sec.
> Am I wrong?
>
> Regards,
> Igor Neyman
>
>
>
> ______________________________________________________________
>
>
> From: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of
> slapo@centrum.sk
> Sent: Wednesday, August 07, 2013 8:43 AM
> To: Pavel Stehule
> Cc: pgsql-performance@postgresql.org
> Subject: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a
> view with another view inside of it.
>
> Good day,
>
> I have included a link to the result of EXPLAIN ANALYZE. It's this one:
> https://app.box.com/s/u8nk6qvkjs4ae7l7dh4h
>
> Here's a link to Depesz's explain (if links to the site are okay):
> http://explain.depesz.com/s/gCk
>
> I have just tried setting geqo_threshold, join_collapse_limit and
> from_collapse_limit to 16, but it yielded no improvement.
> Changing those three parameters to 32 did speed up the query from about 3.3
> seconds to about a second (give or take 50 ms), which is a pretty good
> improvement, but not quite there, as I'm looking to bring it down to about
> 300 ms if possible. Changing those three settings to 48 yielded no
> improvements over 32.
> Is there possibly something something else to tweak there?
>
> Here's EXPLAIN ANALYZE output when the three settings have been set to 32:
> http://explain.depesz.com/s/cj2
>
> Thank you.
>
> Peter Slapansky
>


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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
Следующее
От:
Дата:
Сообщение: RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.