Re: Shared memory and memory context question

> On Sun February 5 2006 16:16, Tom Lane wrote:
>> AFAICT the data structures you are worried about don't have any readily
>> predictable size, which means there is no good way to keep them in
>> shared memory --- we can't dynamically resize shared memory. So I think
>> storing the rules in a table and loading into private memory at need is
>> really the only reasonable solution. Storing them in a table has a lot
>> of other advantages anyway, mainly that you can manipulate them from
>> SQL.
>
> I have come to the conclusion that storing the rules and various other
> bits in
> tables is the best solution, although this will require a much more
> complex
> db structure than I had originally planned. Trying to allocate and free
> memory in shared memory is fairly straightforward, but likely to become
> incredibly messy.
>
> Seeing as some of the rules already include load-value-from-db-on-demand,
> it
> should be fairly straightforward to extend it to
> load-rule-from-db-on-demand.
>

I posted some source to a shared memory sort of thing to the group, as
well as to you, I believe.

For variables and values that change very infrequently, using the DB is
the right idea. PostgreSQL, as well as most databases, crumble under a
highly changing database. By changing, I mean a lot of UPDATES and
DELETES. Inserts are not so bad. PostgreSQL has a fairl poor (IMHO) UPDATE
behaviour. Most transaction aware databases do, but PostgreSQL seems quite
bad.

For an example, if you are doing a scoreboard sort of thing for a website,
updating a single varible in a table 20 times a second, will quickly make
that simple and normally fast update/query take a very long time. You have
to run VACUUM a whole lot.

The next example is a session table for a website, you may have a few
hundred or a few thousand active session rows, but each row may get many
updates, and you may have tens of thousands of sessions which may be
inactive. Unless you vaccum very frequently, you are doing a lot of disk
I/O for every session, because the query has to walk the table file to
find a valid row.

A database is a BAD system to manage data like sessions in an active
website. It is a good tool for most all, but if you are implementing an
eBay or Yahoo, you'll swamp your DB quickly.

The issue with a shared memory system is that you don't get the data
security that you do with disk storage.