Re: Can I get some PostgreSQL developer feedback on these five general issues I have with PostgreSQL and its ecosystem? - Mailing list pgsql-general

From Peter J. Holzer
Subject Re: Can I get some PostgreSQL developer feedback on these five general issues I have with PostgreSQL and its ecosystem?
Date
Msg-id 20201003075440.GA18543@hjp.at
Whole thread Raw
In response to Re: Can I get some PostgreSQL developer feedback on these five general issues I have with PostgreSQL and its ecosystem?  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
On 2020-09-23 13:38:19 -0700, Adrian Klaver wrote:
> On 9/23/20 11:51 AM, tutiluren@tutanota.com wrote:
> >     This comes down to what your definition of embedded is? A matter of
> >     determining whether we are talking apples or oranges.
> >
> > Just what I said in my original question. Something which is bundled and
> > invisible to the user.
>
> That is going to be difficult with Postgres as it is its own process. It
> would take a good bit of tooling to hide that from the user.

I guess that comes down to the definition of "invisible". PostgreSQL
certainly won't be invisible to a user running «ps -e» on Linux or using
the task manager on Windows. It also won't be invisible to someone who
examines the file system and discovers a directory structure with
PostgreSQL's rather distinctive file names (the latter is of course true
for SQLite, too).

But I don't see any great difficulty in bundling PostgreSQL with an
application, such that it is automatically installed, configured,
populated and managed by the application. The user might never notice
that it's there at all.

But this is the responsibility of the application's author: The author
can put work into an installer or they can decide that it's better (for
some definition of "better") to tell the user to install PostgreSQL
themselves. It has very little to do with PostgreSQL.


> It is more then that. It would have to take into account the behavior
> changes that happen in Postgres between major versions. It also would have
> to account for OS specific parameters and the changes that happen there
> between OS versions. It also would need to 'know' how the database was going
> to be used;

This is IMHO the most important point: Memory, CPUs, OS versions: There
is only so much variety. But how the database is used - that can be very
different. For example, on our largest database server I have work_mem
set to 1/8 of the total RAM. This is not something I would recommend
generally, but it works well for our workload. And most importantly it
isn't something that can be determined statically - it depends on the
behaviour of the application. So either you already know that (which I,
as the author of our application do (mostly), but a Postgres tuning tool
can't) or you observe the application for some time (weeks, probably)
and adjust parameters (this is something a tool could do, and maybe
better than a human, but this is getting into AI territory).

        hp

--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

Attachment

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: UUID generation problem
Next
From: Paul Förster
Date:
Subject: Re: UUID generation problem