Re: Potential performance issues

Was just about to reply similarly. Mind you it perhaps does raise the
question : are the default postgresql settings perhaps too
conservative or too static. For example, in the absence of other
explicit configuration, might it make more sense for many use cases
for postgres to assess the physical memory available and make some
half-sensible allocations based on that? I know there are downsides
to assuming that postgresql has free reign to all that it sees, but
there are clearly also some downsides in assuming it has next to
nothing. This could also be more correctly part of a package
installation procedure, but just floating the idea ... some kind of
auto-tuning vs ultra-conservative defaults.

On Mon, 1 Mar 2021 at 13:05, MichaelDBA <MichaelDBA(at)sqlexec(dot)com> wrote:
>
> Ha, Andrew beat me to the punch!
>
> Andrew Dunstan wrote on 3/1/2021 7:59 AM:
> > On 2/28/21 10:04 AM, Jung, Jinho wrote:
> >> # install DBMS
> >> sudo su
> >> make install
> >> adduser postgres
> >> rm -rf /usr/local/pgsql/data
> >> mkdir /usr/local/pgsql/data
> >> chown -R postgres /usr/local/pgsql/data
> >> su - postgres
> >> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
> >> /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start
> >> /usr/local/pgsql/bin/createdb jjung
> >
> > Using an untuned Postgres is fairly useless for a performance test. Out
> > of the box, shared_buffers and work_mem are too low for almost all
> > situations, and many other settings can also usually be improved. The
> > default settings are deliberately very conservative.
> >
> >
> > cheers
> >
> >
> > andrew
> >
> >
> >
> > -- Andrew Dunstan EDB: https://www.enterprisedb.com
> >
> >
>
>
>