pg.ddx.io pgsql-general@postgresql.org mailing list archive
help / color / mirror / Atom feedShared Buffers
17+ messages / 14 participants
[nested] [flat]
* Shared Buffers
@ 2001-06-21 20:17 Dennis <dennis@zserve.com>
2001-06-22 00:41 ` Re: Shared Buffers Thalis A. Kalfigopoulos <thalis@cs.pitt.edu>
0 siblings, 1 reply; 17+ messages in thread
From: Dennis @ 2001-06-21 20:17 UTC (permalink / raw)
To: pgsql-general
When starting postmaster, you can add the -B option to indicate the amount
of shared buffers you want postgres to use. You can also specify the value
in postgresql.conf.
I read in the documentation that 1 shared buffer is 8192 bytes. Somone
posted a while back that it was most optimal to let postgres have about 1/4
of the memory on a dedicated machine.
So, I have 512 megs on a dedicated machine. I divide that by 4 and then
times the number of bytes in a meg and divide by 8192 and I get 16384.
By the 1/4 standard, it seems I should set "-B 16384" at postgres startup.
Postgres defaults to 64 Shared Buffers. That is a big difference from
16384. Is there any reason to my logic here or am I way off?
Can anyone supply some more information or maybe suggest the most
optimum way to use Shared Buffers. Is the 1/4 standard good or should
I use even more.. or much less?
Thanks in advance.
Dennis
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Shared Buffers
2001-06-21 20:17 Shared Buffers Dennis <dennis@zserve.com>
@ 2001-06-22 00:41 ` Thalis A. Kalfigopoulos <thalis@cs.pitt.edu>
0 siblings, 0 replies; 17+ messages in thread
From: Thalis A. Kalfigopoulos @ 2001-06-22 00:41 UTC (permalink / raw)
To: Dennis <dennis@zserve.com>; +Cc: pgsql-general
I had the same quetions more or less. I have 256Mb ram and set it according to the 1/4 rule to ~64M (shared_buffers=7500) after raising the /proc/sys/kernel/shmall and shmmax to 64M
Today I decided to go for double the money, and switched to 128M shmem and restarted postgres with shared_buffers=15000 (8192*15000=~120M). I didn't notice any difference :)
I assume that by "shared buffers" Pg means the area where common data is stored and by common data it means "index blocks" (can't think what else can be shared between processes/queries). So unless you get many users hitting different tables, you won't notice a difference.
Is there a shred of truth in this or am I...?
cheers,
thalis
On Thu, 21 Jun 2001, Dennis wrote:
>
> When starting postmaster, you can add the -B option to indicate the amount
> of shared buffers you want postgres to use. You can also specify the value
> in postgresql.conf.
>
> I read in the documentation that 1 shared buffer is 8192 bytes. Somone
> posted a while back that it was most optimal to let postgres have about 1/4
> of the memory on a dedicated machine.
>
> So, I have 512 megs on a dedicated machine. I divide that by 4 and then
> times the number of bytes in a meg and divide by 8192 and I get 16384.
> By the 1/4 standard, it seems I should set "-B 16384" at postgres startup.
>
> Postgres defaults to 64 Shared Buffers. That is a big difference from
> 16384. Is there any reason to my logic here or am I way off?
>
> Can anyone supply some more information or maybe suggest the most
> optimum way to use Shared Buffers. Is the 1/4 standard good or should
> I use even more.. or much less?
>
> Thanks in advance.
> Dennis
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
^ permalink raw reply [nested|flat] 17+ messages in thread
* shared buffers
@ 2004-10-25 20:31 Glenn Sullivan <glenn.sullivan@varianinc.com>
2004-10-25 21:08 ` Re: shared buffers Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 17+ messages in thread
From: Glenn Sullivan @ 2004-10-25 20:31 UTC (permalink / raw)
To: pgsql-general
Hi,
In the 7.4.5 version, the code is now trying to use a much larger
value for shared_buffers. I can certainly set this to a lower number
with the -B option. However, my guestion is:
What is the performance issue with setting shared_buffers to something like 45?
In doing some timing on my system, I cannot tell any difference with 45 versus 1000.
Perhaps I am looking at the wrong performance criteria.
Thanks,
Glenn
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: shared buffers
2004-10-25 20:31 shared buffers Glenn Sullivan <glenn.sullivan@varianinc.com>
@ 2004-10-25 21:08 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 17+ messages in thread
From: Tom Lane @ 2004-10-25 21:08 UTC (permalink / raw)
To: Glenn Sullivan <glenn.sullivan@varianinc.com>; +Cc: pgsql-general
Glenn Sullivan <glenn.sullivan@varianinc.com> writes:
> What is the performance issue with setting shared_buffers to something like 45?
> In doing some timing on my system, I cannot tell any difference with 45 versus 1000.
What are you timing exactly? Almost every benchmark I've ever seen is
much happier with shared_buffers of at least a few hundred. Otherwise
you spend too much time copying data between kernel and user space.
regards, tom lane
^ permalink raw reply [nested|flat] 17+ messages in thread
* Shared buffers
@ 2006-07-27 11:58 Christian Rengstl <Christian.Rengstl@klinik.uni-regensburg.de>
2006-07-27 21:00 ` Re: Shared buffers Shoaib Mir <shoaibmir@gmail.com>
0 siblings, 1 reply; 17+ messages in thread
From: Christian Rengstl @ 2006-07-27 11:58 UTC (permalink / raw)
To: pgsql-general
Hi list,
just wanted to ask what is a "good/reasonable" value for the shared_bufferes variable. Right now i set it to 64000 on a windows 2003 server with 1GB ram and 3.2 GHz which runs as file server (for only a small number of users) and db server.
Thanks
--
Christian Rengstl M.A.
Klinik und Poliklinik für Innere Medizin II
Kardiologie - Forschung
Universitätsklinikum Regensburg
B3 1.388
Franz-Josef-Strauss-Allee 11
93053 Regensburg
Tel.: +49-941-944-7230
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Shared buffers
2006-07-27 11:58 Shared buffers Christian Rengstl <Christian.Rengstl@klinik.uni-regensburg.de>
@ 2006-07-27 21:00 ` Shoaib Mir <shoaibmir@gmail.com>
2006-07-28 23:18 ` Re: Shared buffers Jim Nasby <jnasby@pervasive.com>
0 siblings, 1 reply; 17+ messages in thread
From: Shoaib Mir @ 2006-07-27 21:00 UTC (permalink / raw)
To: pgsql-general
Go to http://www.powerpostgresql.com/PerfList/ and see the shared_buffers
settings section there.
Thanks,
--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
On 7/27/06, Christian Rengstl <Christian.Rengstl@klinik.uni-regensburg.de>
wrote:
>
> Hi list,
>
> just wanted to ask what is a "good/reasonable" value for the
> shared_bufferes variable. Right now i set it to 64000 on a windows 2003
> server with 1GB ram and 3.2 GHz which runs as file server (for only a
> small number of users) and db server.
>
> Thanks
>
> --
> Christian Rengstl M.A.
> Klinik und Poliklinik für Innere Medizin II
> Kardiologie - Forschung
> Universitätsklinikum Regensburg
> B3 1.388
> Franz-Josef-Strauss-Allee 11
> 93053 Regensburg
> Tel.: +49-941-944-7230
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Shared buffers
2006-07-27 11:58 Shared buffers Christian Rengstl <Christian.Rengstl@klinik.uni-regensburg.de>
2006-07-27 21:00 ` Re: Shared buffers Shoaib Mir <shoaibmir@gmail.com>
@ 2006-07-28 23:18 ` Jim Nasby <jnasby@pervasive.com>
0 siblings, 0 replies; 17+ messages in thread
From: Jim Nasby @ 2006-07-28 23:18 UTC (permalink / raw)
To: Shoaib Mir <shoaibmir@gmail.com>; +Cc: pgsql-general
Note that starting in 8.0/8.1, you can sometimes get very large gains
by setting shared_buffers very high; 1/2 of memory or more.
On Jul 27, 2006, at 4:00 PM, Shoaib Mir wrote:
> Go to http://www.powerpostgresql.com/PerfList/ and see the
> shared_buffers settings section there.
>
> Thanks,
> --
> Shoaib Mir
> EnterpriseDB ( www.enterprisedb.com)
>
>
> On 7/27/06, Christian Rengstl <Christian.Rengstl@klinik.uni-
> regensburg.de > wrote:Hi list,
>
> just wanted to ask what is a "good/reasonable" value for the
> shared_bufferes variable. Right now i set it to 64000 on a windows
> 2003 server with 1GB ram and 3.2 GHz which runs as file server (for
> only a small number of users) and db server.
>
> Thanks
>
> --
> Christian Rengstl M.A.
> Klinik und Poliklinik für Innere Medizin II
> Kardiologie - Forschung
> Universitätsklinikum Regensburg
> B3 1.388
> Franz-Josef-Strauss-Allee 11
> 93053 Regensburg
> Tel.: +49-941-944-7230
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
>
>
>
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
^ permalink raw reply [nested|flat] 17+ messages in thread
* Shared Buffers
@ 2009-03-02 13:11 Siddharth Shah <siddharth.shah@elitecore.com>
2009-03-02 13:31 ` Re: Shared Buffers Ashish Karalkar <ashishka@synechron.com>
2009-03-02 14:40 ` Re: Shared Buffers Gauthier, Dave <dave.gauthier@intel.com>
0 siblings, 2 replies; 17+ messages in thread
From: Siddharth Shah @ 2009-03-02 13:11 UTC (permalink / raw)
To: pgsql-general
Hello All,
How Postgres Maintains data in Shared Buffer
Does It maintains queried data in memory or table data and Next time how
postgres fetch data from memory
rather than disk
Which algorithm is used for storing data how data is indexed in shared
buffers
Thanks
Siddharth
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Shared Buffers
2009-03-02 13:11 Shared Buffers Siddharth Shah <siddharth.shah@elitecore.com>
@ 2009-03-02 13:31 ` Ashish Karalkar <ashishka@synechron.com>
2009-03-02 13:48 ` Re: Shared Buffers Grzegorz Jaśkiewicz <gryzman@gmail.com>
1 sibling, 1 reply; 17+ messages in thread
From: Ashish Karalkar @ 2009-03-02 13:31 UTC (permalink / raw)
To: Siddharth Shah <siddharth.shah@elitecore.com>; +Cc: pgsql-general
Siddharth Shah wrote:
>
> Hello All,
> How Postgres Maintains data in Shared Buffer
>
> Does It maintains queried data in memory or table data and Next time
> how postgres fetch data from memory
> rather than disk
> Which algorithm is used for storing data how data is indexed in shared
> buffers
>
> Thanks
> Siddharth
Take a look at
http://www.westnet.com/~gsmith/content/postgresql/InsideBufferCache.pdf
http://postgresql.mirrors-r-us.net/files/documentation/books/aw_pgsql/hw_performance/node3.html
--Ashish
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Shared Buffers
2009-03-02 13:11 Shared Buffers Siddharth Shah <siddharth.shah@elitecore.com>
2009-03-02 13:31 ` Re: Shared Buffers Ashish Karalkar <ashishka@synechron.com>
@ 2009-03-02 13:48 ` Grzegorz Jaśkiewicz <gryzman@gmail.com>
0 siblings, 0 replies; 17+ messages in thread
From: Grzegorz Jaśkiewicz @ 2009-03-02 13:48 UTC (permalink / raw)
To: Ashish Karalkar <ashishka@synechron.com>; +Cc: Siddharth Shah <siddharth.shah@elitecore.com>; pgsql-general
On Mon, Mar 2, 2009 at 1:31 PM, Ashish Karalkar <ashishka@synechron.com> wrote:
> Take a look at
>
> http://www.westnet.com/~gsmith/content/postgresql/InsideBufferCache.pdf
>
> http://postgresql.mirrors-r-us.net/files/documentation/books/aw_pgsql/hw_performance/node3.html
Wouldn't it be nice, to have any presentation's like that one made by
Greg, in wiki, or part of devel docs ?
--
GJ
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Shared Buffers
2009-03-02 13:11 Shared Buffers Siddharth Shah <siddharth.shah@elitecore.com>
@ 2009-03-02 14:40 ` Gauthier, Dave <dave.gauthier@intel.com>
2009-03-04 06:51 ` Re: Shared Buffers Scott Marlowe <scott.marlowe@gmail.com>
1 sibling, 1 reply; 17+ messages in thread
From: Gauthier, Dave @ 2009-03-02 14:40 UTC (permalink / raw)
To: Siddharth Shah <siddharth.shah@elitecore.com>; pgsql-general
I believe that op system side buffering can play a role too. I our case, the DB server (machine & op sys) caches data that it pulled from disk (not necessarily from a DB) and also the disk servers do the same. If a block was removed from the DB buffer cache to accommodate more recently requested data, but the evicted block is live in memory on the DB server or the disk server, it can pull from there instead of performing an expensive disk-IO.
I humbly defer to any out there with more knowledge about this than I. Just opening up this avenue for discussion.
-dave
________________________________
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Siddharth Shah
Sent: Monday, March 02, 2009 8:12 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Shared Buffers
Hello All,
How Postgres Maintains data in Shared Buffer
Does It maintains queried data in memory or table data and Next time how postgres fetch data from memory
rather than disk
Which algorithm is used for storing data how data is indexed in shared buffers
Thanks
Siddharth
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: Shared Buffers
2009-03-02 13:11 Shared Buffers Siddharth Shah <siddharth.shah@elitecore.com>
2009-03-02 14:40 ` Re: Shared Buffers Gauthier, Dave <dave.gauthier@intel.com>
@ 2009-03-04 06:51 ` Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 0 replies; 17+ messages in thread
From: Scott Marlowe @ 2009-03-04 06:51 UTC (permalink / raw)
To: Gauthier, Dave <dave.gauthier@intel.com>; +Cc: Siddharth Shah <siddharth.shah@elitecore.com>; pgsql-general
On Mon, Mar 2, 2009 at 7:40 AM, Gauthier, Dave <dave.gauthier@intel.com> wrote:
> I believe that op system side buffering can play a role too. I our case,
> the DB server (machine & op sys) caches data that it pulled from disk (not
> necessarily from a DB) and also the disk servers do the same. If a block
> was removed from the DB buffer cache to accommodate more recently requested
> data, but the evicted block is live in memory on the DB server or the disk
> server, it can pull from there instead of performing an expensive disk-IO.
This is very true for certain workloads. If your db is bigger than
memory, and you only work on a tiny bit at a time, the kernel is often
better at caching than pgsql. Run something like pgbench on a machine
with say 4 Gig of memory and a 40 Gig pgbench db dir, and you're
better off with 128M or something for shared_buffers than 1G often
times. Truly random small access, has, for me, worked better with
moderate to smaller shared_buffers. Plus if you need to run a few
memory hog queries, the kernel can flush out some free memory from
cache quickly, but shared_buffers is static. So, the kernel file
cache is self tuning.
But you'll have to test it with your application to really see.
^ permalink raw reply [nested|flat] 17+ messages in thread
* shared buffers
@ 2023-08-17 15:47 Marc Millas <marc.millas@mokadb.com>
0 siblings, 0 replies; 17+ messages in thread
From: Marc Millas @ 2023-08-17 15:47 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Hi,
to my understanding it use to be "common sense" to limit shared buffers,
maybe around 32 GB.
due to ressources consumption of managing said cache.
I would like to know if, on a v15 with 256 GB RAM, setting shared buffers
to say 96 GB would benefit large BI queries ?
Or to say it differently, what could be advantages/disadvantages of such a
setup ?
thanks
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
^ permalink raw reply [nested|flat] 17+ messages in thread
* shared buffers
@ 2025-04-25 13:42 Marc Millas <marc.millas@mokadb.com>
2025-04-25 16:13 ` Re: shared buffers Marc Millas <marc.millas@mokadb.com>
2025-04-25 22:46 ` Re: shared buffers Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 2 replies; 17+ messages in thread
From: Marc Millas @ 2025-04-25 13:42 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
hello,
got something strange to me:
Same db ie. same data, around 1.2TB,one on pg13, one on pg16
same 16 GB of shared_buffers,
I am the single user.
both have track_io_timing on
on pg13, if I run a big request with explain (analyze,buffers),
I see around 6 GB read
if I do rerun the very same request, no more read(s), all data in the
shared buffers cache. fine
If I check with pg_buffercache what's in it, I see the biggest tables of my
request within the biggest users (in number of blocks used). All this is
fine.
next, if I do the very same on the pg16 machine, whatever the number of
times I rerun the explain (analyze, buffers) of the same request, each
time, the explain shows the same volume of reads. again and again.
If I check with pg_buffercache, the set of objects stay the same, WITHOUT
the objects of my request, just like if those objects where sticky.
any idea ?
thanks
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: shared buffers
2025-04-25 13:42 shared buffers Marc Millas <marc.millas@mokadb.com>
@ 2025-04-25 16:13 ` Marc Millas <marc.millas@mokadb.com>
1 sibling, 0 replies; 17+ messages in thread
From: Marc Millas @ 2025-04-25 16:13 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Sorry,
'someone' launches some kind of batches without telling.
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
On Fri, Apr 25, 2025 at 3:42 PM Marc Millas <marc.millas@mokadb.com> wrote:
> hello,
>
> got something strange to me:
> Same db ie. same data, around 1.2TB,one on pg13, one on pg16
> same 16 GB of shared_buffers,
> I am the single user.
> both have track_io_timing on
>
> on pg13, if I run a big request with explain (analyze,buffers),
> I see around 6 GB read
> if I do rerun the very same request, no more read(s), all data in the
> shared buffers cache. fine
> If I check with pg_buffercache what's in it, I see the biggest tables of
> my request within the biggest users (in number of blocks used). All this is
> fine.
>
> next, if I do the very same on the pg16 machine, whatever the number of
> times I rerun the explain (analyze, buffers) of the same request, each
> time, the explain shows the same volume of reads. again and again.
> If I check with pg_buffercache, the set of objects stay the same, WITHOUT
> the objects of my request, just like if those objects where sticky.
>
> any idea ?
>
> thanks
>
> Marc MILLAS
> Senior Architect
> +33607850334
> www.mokadb.com
>
>
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: shared buffers
2025-04-25 13:42 shared buffers Marc Millas <marc.millas@mokadb.com>
@ 2025-04-25 22:46 ` Laurenz Albe <laurenz.albe@cybertec.at>
2025-04-28 11:05 ` Re: shared buffers Marc Millas <marc.millas@mokadb.com>
1 sibling, 1 reply; 17+ messages in thread
From: Laurenz Albe @ 2025-04-25 22:46 UTC (permalink / raw)
To: Marc Millas <marc.millas@mokadb.com>; pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
On Fri, 2025-04-25 at 15:42 +0200, Marc Millas wrote:
> got something strange to me:
> Same db ie. same data, around 1.2TB,one on pg13, one on pg16
> same 16 GB of shared_buffers,
> I am the single user.
> both have track_io_timing on
>
> on pg13, if I run a big request with explain (analyze,buffers),
> I see around 6 GB read
> if I do rerun the very same request, no more read(s), all data in the shared buffers cache. fine
> If I check with pg_buffercache what's in it, I see the biggest tables of my request within
> the biggest users (in number of blocks used). All this is fine.
>
> next, if I do the very same on the pg16 machine, whatever the number of times I rerun the
> explain (analyze, buffers) of the same request, each time, the explain shows the same volume
> of reads. again and again.
> If I check with pg_buffercache, the set of objects stay the same, WITHOUT the objects of my
> request, just like if those objects where sticky.
I can't see the plans, so I can only guess.
Perhaps the v16 plan uses a sequential scan on a table that is more than a quarter of
shared_buffers in size, so that PostgreSQL uses a ring buffer to read it instead of
blowing out more than a quarter of its buffer cache.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: shared buffers
2025-04-25 13:42 shared buffers Marc Millas <marc.millas@mokadb.com>
2025-04-25 22:46 ` Re: shared buffers Laurenz Albe <laurenz.albe@cybertec.at>
@ 2025-04-28 11:05 ` Marc Millas <marc.millas@mokadb.com>
0 siblings, 0 replies; 17+ messages in thread
From: Marc Millas @ 2025-04-28 11:05 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
I didnt know this.
thanks,
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
On Sat, Apr 26, 2025 at 12:46 AM Laurenz Albe <laurenz.albe@cybertec.at>
wrote:
> On Fri, 2025-04-25 at 15:42 +0200, Marc Millas wrote:
> > got something strange to me:
> > Same db ie. same data, around 1.2TB,one on pg13, one on pg16
> > same 16 GB of shared_buffers,
> > I am the single user.
> > both have track_io_timing on
> >
> > on pg13, if I run a big request with explain (analyze,buffers),
> > I see around 6 GB read
> > if I do rerun the very same request, no more read(s), all data in the
> shared buffers cache. fine
> > If I check with pg_buffercache what's in it, I see the biggest tables of
> my request within
> > the biggest users (in number of blocks used). All this is fine.
> >
> > next, if I do the very same on the pg16 machine, whatever the number of
> times I rerun the
> > explain (analyze, buffers) of the same request, each time, the explain
> shows the same volume
> > of reads. again and again.
> > If I check with pg_buffercache, the set of objects stay the same,
> WITHOUT the objects of my
> > request, just like if those objects where sticky.
>
> I can't see the plans, so I can only guess.
>
> Perhaps the v16 plan uses a sequential scan on a table that is more than a
> quarter of
> shared_buffers in size, so that PostgreSQL uses a ring buffer to read it
> instead of
> blowing out more than a quarter of its buffer cache.
>
> Yours,
> Laurenz Albe
>
^ permalink raw reply [nested|flat] 17+ messages in thread
end of thread, other threads:[~2025-04-28 11:05 UTC | newest]
Thread overview: 17+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2001-06-21 20:17 Shared Buffers Dennis <dennis@zserve.com>
2001-06-22 00:41 ` Thalis A. Kalfigopoulos <thalis@cs.pitt.edu>
2004-10-25 20:31 shared buffers Glenn Sullivan <glenn.sullivan@varianinc.com>
2004-10-25 21:08 ` Re: shared buffers Tom Lane <tgl@sss.pgh.pa.us>
2006-07-27 11:58 Shared buffers Christian Rengstl <Christian.Rengstl@klinik.uni-regensburg.de>
2006-07-27 21:00 ` Re: Shared buffers Shoaib Mir <shoaibmir@gmail.com>
2006-07-28 23:18 ` Re: Shared buffers Jim Nasby <jnasby@pervasive.com>
2009-03-02 13:11 Shared Buffers Siddharth Shah <siddharth.shah@elitecore.com>
2009-03-02 13:31 ` Ashish Karalkar <ashishka@synechron.com>
2009-03-02 13:48 ` Grzegorz Jaśkiewicz <gryzman@gmail.com>
2009-03-02 14:40 ` Gauthier, Dave <dave.gauthier@intel.com>
2009-03-04 06:51 ` Scott Marlowe <scott.marlowe@gmail.com>
2023-08-17 15:47 shared buffers Marc Millas <marc.millas@mokadb.com>
2025-04-25 13:42 shared buffers Marc Millas <marc.millas@mokadb.com>
2025-04-25 16:13 ` Re: shared buffers Marc Millas <marc.millas@mokadb.com>
2025-04-25 22:46 ` Re: shared buffers Laurenz Albe <laurenz.albe@cybertec.at>
2025-04-28 11:05 ` Re: shared buffers Marc Millas <marc.millas@mokadb.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox