Re: Performance of the temporary table creation and use.

From: Luiz Gonzaga da Mata <gonzaga(at)pbh(dot)gov(dot)br>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Performance of the temporary table creation and use.
Date: 2005-01-26 17:17:43
Message-ID: 41F7D0B7.2030503@pbh.gov.br
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane escreveu:

>Luiz Gonzaga da Mata <gonzaga(at)pbh(dot)gov(dot)br> writes:
>
>
>> Although to have changed they sort_mem/work_mem it for 1 MB, it did not
>>use this area in available memory for the connection to make the
>>creation of the temporary table.
>>
>>
>
>Why would you expect it to, and why would you think there is any
>advantage? A small, short-lived temp table will probably never actually
>be spilled to disk by the kernel (we never fsync them) so the actual
>performance improvement would be minimal.
>
>
>
It can be that kernel not writing physically in disk, but can be also
that write.

If the use to order by, distinct, creating index and other temporary
resources is to greater then it sort_mem/work_mem per processes, the
creating resource in disk can be used.

If to create a concept of work_mem_pool internally, we could optimize
the resources of SO X SGDB and and the use most rational of resource..

For the administrator of the operational system and the administrator of
the SGDB that is very important.

Work_mem_pool = (number of connections->postgresql.conf) X
(work_mem->postgresql.conf).

If *memory real used* for all the user processes will be minor who
work_mem_pool, would use more resources in memory of that simply the
value of work_mem individual.

The general behavior of the PostgreSQL would be very better.

regards,

Luiz Gonzaga da Mata

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message noman naeem 2005-01-26 17:58:08 Data statement format used by the .sh scripts
Previous Message Alvaro Herrera 2005-01-26 16:56:39 Re: bug w/ cursors and savepoints