Обсуждение: pgSql Memory footprint

Поиск
Список
Период
Сортировка

pgSql Memory footprint

От
Ish Ahluwalia
Дата:
Hi:

Can anyone provide a rough guesstimate on how much memory does fully
conigured, with all the services turned on pgSql database require?

I'm trying to make an estimate on how much memory would be required in
Flash and RAM to run pgSql database.

Thanks.

Ish...

Re: pgSql Memory footprint

От
Richard Huxton
Дата:
On Friday 12 September 2003 20:43, Ish Ahluwalia wrote:
> Hi:
>
> Can anyone provide a rough guesstimate on how much memory does fully
> conigured, with all the services turned on pgSql database require?
>
> I'm trying to make an estimate on how much memory would be required in
> Flash and RAM to run pgSql database.

Depends on how many users and what queries you are running. The less RAM you
have available, the more disk I/O there will be.

Can you give more details of what sort of system you are trying to build?
--
  Richard Huxton
  Archonet Ltd

Re: pgSql Memory footprint

От
Ish Ahluwalia
Дата:
In article <200309132112.45526.dev@archonet.com>, dev@archonet.com
says...
> On Friday 12 September 2003 20:43, Ish Ahluwalia wrote:
> > Hi:
> >
> > Can anyone provide a rough guesstimate on how much memory does fully
> > conigured, with all the services turned on pgSql database require?
> >
> > I'm trying to make an estimate on how much memory would be required in
> > Flash and RAM to run pgSql database.
>
> Depends on how many users and what queries you are running. The less RAM you
> have available, the more disk I/O there will be.
>
> Can you give more details of what sort of system you are trying to build?
>
Hi Richard:

Thanks for the resply.  We're looking to use pgSql in a embedded systems
environment especially for a telecom switch.  Memory may not be that big
of a issue as we plan to have a reasonable size flash and decent RAM too
(64 to 128 Mb - which is a lot for embedded systems).  The idea here is
to use the database as a way to store information for all the processes
that may be running.  The memory footprint I was looking for relates to
the disk storage required to store the loadable module/or binary program
on the flash disk, and also some insight into RAM required to run the
databse.  The configuration would be achieve highest speed with most
amount of reliability.  Any rough estimate into worst case memory usage
will be very beneficial?

Thanks in advance.

Ish...

Re: pgSql Memory footprint

От
Tom Lane
Дата:
Ish Ahluwalia <ahluwalia@erinc.com> writes:
> Thanks for the resply.  We're looking to use pgSql in a embedded systems
> environment especially for a telecom switch.  Memory may not be that big
> of a issue as we plan to have a reasonable size flash and decent RAM too
> (64 to 128 Mb - which is a lot for embedded systems).  The idea here is
> to use the database as a way to store information for all the processes
> that may be running.

You'd probably be happier with something like Berkeley DB.  PG isn't
really designed for that sort of thing --- just to start with, you don't
want to point it at flash RAM as "disk" storage, because your flash RAM
life expectancy of ~10000 write cycles won't last long.

            regards, tom lane

Re: pgSql Memory footprint

От
Ian Harding
Дата:
Tom Lane wrote:

>Ish Ahluwalia <ahluwalia@erinc.com> writes:
>
>
>>Thanks for the resply.  We're looking to use pgSql in a embedded systems
>>environment especially for a telecom switch.  Memory may not be that big
>>of a issue as we plan to have a reasonable size flash and decent RAM too
>>(64 to 128 Mb - which is a lot for embedded systems).  The idea here is
>>to use the database as a way to store information for all the processes
>>that may be running.
>>
>>
>
>You'd probably be happier with something like Berkeley DB.  PG isn't
>really designed for that sort of thing --- just to start with, you don't
>want to point it at flash RAM as "disk" storage, because your flash RAM
>life expectancy of ~10000 write cycles won't last long.
>
>            regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 7: don't forget to increase your free space map settings
>
>------------------------------------------------------------------------
>
>SPAM: REFERENCES           (-6.6 points)  Has a valid-looking References header
>SPAM: IN_REP_TO            (-3.3 points)  Has a In-Reply-To header
>SPAM: X_MAILING_LIST       (-0.0 points)  Has a X-Mailing-List header
>Score Total: -9.9
>
Not that I think it is a good idea... But is there any way to reduce the
impact on a flash memory 'disk' by tweaking some PostgreSQL knobs in
usually unadvisable ways?  Also, if you have an enormous amount of flash
memory, isn't that 10,000 writes more than 10.000 writes?  I read
somewhere that flash disks try to 'spread out' the wear and tear over
all available 'cells' on the media.  If the database was used mostly for
selects, with only seldom update/insert/delete, would this idea make
more sense?  I understand that this particular application would not fit
that profile, but there may be others where a full-on SQL database might
be desirable, but that would have few data modifications.

Thanks!!

Ian