Re: query slow; strace output worrisome

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: query slow; strace output worrisome
Дата
Msg-id 4BBBEED4.1000807@postnewspapers.com.au
обсуждение исходный текст
Ответ на Re: query slow; strace output worrisome  (Brian Cox <brian.cox@ca.com>)
Ответы Re: query slow; strace output worrisome  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-performance
On 7/04/2010 12:24 AM, Brian Cox wrote:
> On 04/06/2010 01:18 AM, Craig Ringer [craig@postnewspapers.com.au] wrote:
>> I'm wondering if the issue is with strace rather than Pg. That is to
>> say, that strace is trying to print:
> Thanks, Craig: I do think that this is a strace issue.
>
>> As for what Pg is doing: creat() returns -1 on error and a file
>> descriptor otherwise, so the return value appears to indicate success.
>> I'm kind of wondering what the Pg backend is actually _doing_ though -
>> if it was using sort temp files you'd expect
>> open()/write()/read()/close() not just creat() calls.
> My quesiton exactly: what is the backend doing calling creat() over and
> over again? Note that this query does complete -- in 30-40 mins.

I'd assume it was tempfile creation, but for the fact that there's
nothing but creat() calls.

However, we can't trust strace. There may be more going on that is being
hidden from strace via limitations on the ptrace syscall imposed by
SELinux / AppArmor / whatever.

I suggest turning on the logging options in Pg that report use of
tempfiles and disk-spilled sorts, then have a look and see if Pg is in
fact using on-disk temp files for sorts or materialized data sets.

If it is, you might find that increasing work_mem helps your query out.

--
Craig Ringer

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: LIMIT causes planner to do Index Scan using a less optimal index
Следующее
От: Yeb Havinga
Дата:
Сообщение: Re: Some question