Re: work_mem

From: MichaelDBA <MichaelDBA(at)sqlexec(dot)com>
To: SASIKUMAR Devaraj <sashikumard(at)yahoo(dot)com>
Cc: holger(at)jakobs(dot)com, pgsql-admin(at)lists(dot)postgresql(dot)org
Subject: Re: work_mem
Date: 2021-04-02 12:49:43
Message-ID: 592e5895-8dbd-1a4f-a87c-af72ac8eea02@sqlexec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

That is a common misconception.  It is not one work_mem buffer per SQL,
but one work_mem buffer per required operation within that SQL.  So you
can have manner work_mem buffers per SQL statement!

Right from the official docs:
work_mem sets the maximum amount of memory to be used by a query
operation (such as a sort or hash table) before writing to temporary
disk files. If this value is specified without units, it is taken as
kilobytes...Note that for a complex query, several sort or hash
operations might be running in parallel; each operation will be allowed
to use as much memory as this value specifies before it starts to write
data into temporary files. Also, several running sessions could be doing
such operations concurrently. Therefore, the total memory used could be
many times the value of|work_mem|; it is necessary to keep this fact in
mind when choosing the value. Sort operations are used for|ORDER
BY|,|DISTINCT|, and merge joins. Hash tables are used in hash joins,
hash-based aggregation, and hash-based processing of|IN|subqueries.

Regards,
Michael Vitale

SASIKUMAR Devaraj wrote on 4/2/2021 8:45 AM:
> Thanks Michael
>
> For example work_mem is 4M and if I had 300 connections connected to
> dB the total memory requirement is 1.2 Gb.
>  So as per my understanding this 1.2 gb is not allocated as soon as
> 300 connections established, but it may vary from 0 to 1.2gb as per
> operations from client. Please confirm
>
> Regards
>
> Sasi
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>
> On Fri, Apr 2, 2021 at 6:09 PM, MichaelDBA
> <MichaelDBA(at)sqlexec(dot)com> wrote:
> Memory is allocated dynamically per internal work_mem buffer
> requests.
>
> SASIKUMAR Devaraj wrote on 4/2/2021 8:37 AM:
> Hi All
>
> As soon as client session is established work_mem will be
> allocated or only when sort happens for that particular session?
> Please advise how the internal behavior? This will help me to
> configure my database memory with high connections
>
> Regards
>
> Sasi
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>
> On Wed, Mar 31, 2021 at 8:52 PM, Holger Jakobs
> <holger(at)jakobs(dot)com> <mailto:holger(at)jakobs(dot)com> wrote:
> You can show any or all settings with the command SHOW.
>
> show work_mem;
> show all;
>
> How many times the amount of work_mem has been allocated
> currently cannot be shown this way. Any sort operation running
> currently allocates it. So it is not identical with the number
> of current queries, because queries can allocate it several times.
>
>
> Am 31. März 2021 16:04:07 MESZ schrieb "Campbell, Lance"
> <lance(at)illinois(dot)edu> <mailto:lance(at)illinois(dot)edu>:
>
> PostgreSQL 12
>
> Is there a query that will tell us at any given time what
> amount of PostgreSQL memory is being used for work_mem?
>
> Thanks,
>
> *LANCE CAMPBELL <https://directory.illinois.edu/person/lance>*
>
> Web Services <https://webtools.illinois.edu/>
>
> Public Affairs <https://publicaffairs.illinois.edu/>
>
> /var/folders/wp/1f6l7hw95y718z976kgnl5f9kr5rtc/T/com.microsoft.Outlook/WebArchiveCopyPasteTempFiles/signature_logo.png
> <http://illinois.edu/>
>
> /Under the Illinois Freedom of Information Act any written
> communication to or from university employees regarding
> university business is a public record and may be subject
> to public disclosure./
>
>
> --
> Holger Jakobs, Bergisch Gladbach
> +49 178 9759012
> - sent from mobile, therefore short -
>
>

In response to

  • Re: work_mem at 2021-04-02 12:45:52 from SASIKUMAR Devaraj

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Campbell, Lance 2021-04-02 13:31:20 Re: work_mem
Previous Message SASIKUMAR Devaraj 2021-04-02 12:45:52 Re: work_mem