pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Daniel Cristian Cruz <danielcristian@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: Large table performance
Date: Sat, 13 Jan 2007 13:55:35 -0200
Message-ID: <48d0cacb0701130755i31ef2017m140c9d2647c8fbea@mail.gmail.com> (raw)
In-Reply-To: <20070113013342.GB3133@uio.no>
References: <376735.48483.qm@web35309.mail.mud.yahoo.com>
	<87553E39-54EA-4DE4-BBEF-6FB250EDE651@fastcrypt.com>
	<20070113013342.GB3133@uio.no>

What if we start a project where we define tests for PostgreSQL
overall performance and individual points with any database structure?
It could be done, throught a SQL logger and statistics, where we can
see complete processess and measure then after. We have many things to
measure, and something that would help here is pg_buffercache (contrib
module). We could define many other tests.

I was thinking about something like that, where an aplication reads
information (from catalog too) about an production database, and use
this information to build a data set of any size, respecting anything
measured before.

Is it too complicated? I'm trying to make programs with C++ and
libpqxx, and successfully used Python with PostgreSQL before (was a
database structure comparer). Python could make it easyer, C++ could
be a chalenge for someone like me.

Someone would like to contribute? When we start the project? :)

On 1/12/07, Steinar H. Gunderson <sgunderson@bigfoot.com> wrote:
> On Fri, Jan 12, 2007 at 07:40:25PM -0500, Dave Cramer wrote:
> > 5000 is pretty low, you need at least 1/4 of memory for an 8.1.x or
> > newer server.
>
> Is this the new "common wisdom"? It looks like at some point, someone here
> said "oh, and it looks like you're better off using large values here for
> 8.1.x and newer", and now everybody seems to repeat it as if it was always
> well-known.
>
> Are there any real benchmarks out there that we can point to? And, if you set
> shared_buffers to half of the available memory, won't the kernel cache
> duplicate more or less exactly the same data? (At least that's what people
> used to say around here, but I guess the kernel cache gets adapted to the
> fact that Postgres won't ask for the most common stuff, ie. the one in the
> shared buffer cache.)
>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
>                http://www.postgresql.org/about/donate
>


-- 
Daniel Cristian Cruz
Analista de Sistemas
Especialista postgreSQL e Linux
Instrutor Certificado Mandriva



view thread (8+ messages)  latest in thread

Message-ID: <48d0cacb0701130755i31ef2017m140c9d2647c8fbea@mail.gmail.com>
Permalink:  ../48d0cacb0701130755i31ef2017m140c9d2647c8fbea@mail.gmail.com/
Also on:    postgresql.org/message-id/48d0cacb0701130755i31ef2017m140c9d2647c8fbea@mail.gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: danielcristian@gmail.com
  Subject: Re: Large table performance
  In-Reply-To: <48d0cacb0701130755i31ef2017m140c9d2647c8fbea@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox