On 1/7/07, Colin Taylor <[EMAIL PROTECTED]> wrote:
Hi there, we've partioned a table (using 8.2) by day due to the 50TB of
data (500k row size, 100G rows) we expect to store it in a year.
Our performance on inserts and selects against the master table is
disappointing, 10x slower (with ony 1 par
On 1/6/07, Colin Taylor <[EMAIL PROTECTED]> wrote:
Hi there, we've partioned a table (using 8.2) by day due to the 50TB of
data (500k row size, 100G rows) we expect to store it in a year.
Our performance on inserts and selects against the master table is
disappointing, 10x slower (with ony 1 pa
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
>
> [ fools around with it for awhile... ] I think this is already fixed
> for 8.2.1. Note the costs of the two related index scans:
I installed 8.2.1 this morning and it works much better.
Craig A. James wrote:
> Postgres functions like count() and max() are "plug ins" which has huge
> architectural advantages. But in pre-8.1 releases, there was a big
> speed penalty for this: functions like count() were very, very slow,
> requiring a full table scan. I think this is vastly improve
Colin,
On 1/6/07 8:37 PM, "Colin Taylor" <[EMAIL PROTECTED]> wrote:
> Hi there, we've partioned a table (using 8.2) by day due to the 50TB of data
> (500k row size, 100G rows) we expect to store it in a year.
> Our performance on inserts and selects against the master table is
> disappointing,
Le dimanche 7 janvier 2007 20:03, Ben a écrit :
> I'd like to optimize my postgres configuration for optimal
> performance under typical load. Unfortunately, as I understand
> things, that implies that I have to have a way to repeat the same
> load each time I try out new settings, so that I can fa
