Re: Postgres low end processing.

From: Stef <svb(at)ucs(dot)co(dot)za>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgres low end processing.
Date: 2003-10-03 16:10:02
Message-ID: 20031003181002.20cc6912.svb@ucs.co.za
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Fri, 03 Oct 2003 11:42:54 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

=> Are you sure you want Postgres, and not something smaller? BDB,
=> or SQL Lite, for example?
I have considered various options, including BDB and SQL Lite, but
alas, it will have to be postgres if it's going to be a database. Otherwise
it will be back to the original idea of flat .idx files :(

=> "Postgres is bloatware by design: it was built to house PhD theses."
=> -- J. Hellerstein (who ought to know)
:o) Believe me, I've been amazed since I encountered postgres v6.3.2
in '98

=> But having said that ... given virtual memory and cramped configuration
=> settings, Postgres would certainly run in an 8M machine. Maybe "crawl"
=> would be a more applicable verb than "run", but you could execute it.

Crawling is ok. Won't differ much from normal operation on a machine like that.
Any tips on how to achieve the most diminutive vmem an conf settings?
I tried to figure this out from the docs, and played around with
backend/storage , but I'm not really winning.

Regards
Stef

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2003-10-03 16:11:17 Re: administration with pgaccess
Previous Message Robert Wille 2003-10-03 16:07:41 Re: LC_COLLATE=C not working

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2003-10-03 16:32:00 Re: Postgres low end processing.
Previous Message Jean-Luc Lachance 2003-10-03 15:48:39 Re: count(*) slow on large tables