On Apr 5, 2005 12:16 AM, Christopher Petrilli <[EMAIL PROTECTED]> wrote:
> Looking at preliminary results from running with shared_buffers at
> 16000, it seems this may be correct. Performance was flatter for a
> BIT longer, but slammed right into the wall and started hitting the
> 3-30 second ran
On Mon, 2005-04-04 at 22:36 -0400, Tom Lane wrote:
> Christopher Petrilli <[EMAIL PROTECTED]> writes:
> > On Apr 4, 2005 12:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> do a test run with *no* indexes on the table, just to see if it behaves
> >> any differently? Basically I was wondering if ind
On Apr 5, 2005 3:48 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > Now some amount of slowdown is to be expected as the indexes get larger,
> > since it ought to take roughly O(log N) time to insert a new entry in an
> > index of size N. The weird thing about your curves is the very sudden
> > jum
On Apr 5, 2005 3:48 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> B-trees aren't unique to PostgreSQL; the explanation developed here
> would work equally well for any database system that used tree-based
> indexes. Do we still think that MySQL can do this when PostgreSQL
> cannot? How?
>
> Do we h
Thomas F.O'Connell wrote:
> I'd use two of your drives to create a mirrored partition where pg_xlog
> resides separate from the actual data.
>
> RAID 10 is probably appropriate for the remaining drives.
>
> Fortunately, you're not using Dell, so you don't have to worry about
> the Perc3/Di RAID
