On Wed, May 15, 2024 at 4:22 PM Robert Treat wrote:
> Nope. Let's do the best bang for the buck improvement and we can see
> if we get any feedback that indicates more needs to be done.
Done.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, May 15, 2024 at 4:05 PM Robert Haas wrote:
>
> On Wed, May 15, 2024 at 4:00 PM Robert Treat wrote:
> > I think the only unresolved question in my mind was if we should add a
> > similar note to the original patch to max_prepared_xacts as well; do
> > you intend to do that?
>
> I didn't in
On Wed, May 15, 2024 at 4:00 PM Robert Treat wrote:
> I think the only unresolved question in my mind was if we should add a
> similar note to the original patch to max_prepared_xacts as well; do
> you intend to do that?
I didn't intend to do that. I don't think it would be incorrect to do
so, bu
On Wed, May 15, 2024 at 11:14 AM Robert Haas wrote:
>
> On Fri, Mar 22, 2024 at 1:57 PM Robert Haas wrote:
> > Rather, I think that it's entirely appropriate to do what Roberto
> > suggested, which is to say, let users know that they're going to use
> > some extra resources if they increase the s
On Fri, Mar 22, 2024 at 1:57 PM Robert Haas wrote:
> Rather, I think that it's entirely appropriate to do what Roberto
> suggested, which is to say, let users know that they're going to use
> some extra resources if they increase the setting, and then let them
> figure out what if anything they wa
On Fri, Mar 8, 2024 at 9:52 AM Robert Treat wrote:
> I'm of the opinion that advice suggestingDBA's set things to DEBUG 3
> is unfriendly at best. If you really want to add more, there is an
> existing unfriendly section of the docs at
> https://www.postgresql.org/docs/devel/kernel-resources.html#
Hi,
On Sun, Mar 10, 2024 at 09:58:25AM -0400, Robert Treat wrote:
> On Fri, Mar 8, 2024 at 10:47 AM Michael Banck wrote:
> > On Fri, Jan 12, 2024 at 10:14:38PM +, Cary Huang wrote:
> > > I think it is good to warn the user about the increased allocation of
> > > memory for certain parameters
On Fri, Mar 8, 2024 at 10:47 AM Michael Banck wrote:
>
> Hi,
>
> On Fri, Jan 12, 2024 at 10:14:38PM +, Cary Huang wrote:
> > I think it is good to warn the user about the increased allocation of
> > memory for certain parameters so that they do not abuse it by setting
> > it to a huge number w
Hi,
On Fri, Jan 12, 2024 at 10:14:38PM +, Cary Huang wrote:
> I think it is good to warn the user about the increased allocation of
> memory for certain parameters so that they do not abuse it by setting
> it to a huge number without knowing the consequences.
Right, and I think it might be u
On Mon, Jan 22, 2024 at 8:58 AM wrote:
> On Fri, 2024-01-19 at 17:37 -0500, reid.thomp...@crunchydata.com wrote:
> > On Sat, 2024-01-13 at 10:31 -0700, Roberto Mello wrote:
> > >
> > > I can add a suggestion for the user to consider increasing
> > > shared_buffers in accordance with higher max_con
On Fri, 2024-01-19 at 17:37 -0500, reid.thomp...@crunchydata.com wrote:
> On Sat, 2024-01-13 at 10:31 -0700, Roberto Mello wrote:
> >
> > I can add a suggestion for the user to consider increasing
> > shared_buffers in accordance with higher max_connections, but it
> > would be better if there was
On Sat, 2024-01-13 at 10:31 -0700, Roberto Mello wrote:
> On Fri, Jan 12, 2024 at 3:15 PM Cary Huang
> wrote:
> > I think it is good to warn the user about the increased allocation
> > of memory for certain parameters so that they do not abuse it by
> > setting it to a huge number without knowing
On Fri, Jan 12, 2024 at 3:15 PM Cary Huang wrote:
> I think it is good to warn the user about the increased allocation of
> memory for certain parameters so that they do not abuse it by setting it to
> a huge number without knowing the consequences.
>
> It is true that max_connections can increas
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I think it is good to warn the user about the increased alloc
The documentation for max_connections does not mention that just by having
a higher value for max_connections, PostgreSQL will use more resources.
While working with different customers, I noticed that several of them set
max_connections to very high numbers, even though they never expected to
act
15 matches
Mail list logo
