Decibel! wrote:
On Thu, Sep 06, 2007 at 11:26:46AM +0200, Willo van der Merwe wrote:
Richard Huxton wrote:
Willo van der Merwe wrote:
Hi guys,
I'm have the rare opportunity to spec the hardware for a new database
server. It's going to replace an older one, driving a social netw
> > Get yourself the ability to benchmark your application. This is
> > invaluable^W a requirement for any kind of performance tuning.
> >
> I'm pretty happy with the performance of the database at this stage.
> Correct me if I'm wrong, but AFAIK a load of 3.5 on a quad is not
> overloading it. It
Decibel! escribió:
> On Tue, Sep 11, 2007 at 09:49:37AM +0200, Ruben Rubio wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> [EMAIL PROTECTED] escribi?:
Last time I had this problem i solved it stopping website, restarting
database, vacuumm it, run again website. But I g
El-Lotso skrev:
> I'm on the verge of giving up... the schema seems simple and yet there's
> so much issues with it. Perhaps it's the layout of the data, I don't
> know. But based on the ordering/normalisation of the data and the one to
> many relationship of some tables, this is giving the planne
El-Lotso <[EMAIL PROTECTED]> writes:
> I'm really at my wits end here.
Try to merge the multiple join keys into one, somehow. I'm not sure why
the planner is overestimating the selectivity of the combined join
conditions, but that's basically where your problem is coming from.
A truly brute-for
Jean-David Beyer escribió:
Gregory Stark wrote (in part):
The extra spindles speed up sequential i/o too so the ratio between sequential
and random with prefetch would still be about 4.0. But the ratio between
sequential and random without prefetch would be even higher.
I never figure
On 9/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Decibel! escribió:
> > On Tue, Sep 11, 2007 at 09:49:37AM +0200, Ruben Rubio wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> [EMAIL PROTECTED] escribi?:
> Last time I had this problem i solved it stopping web
Scott Marlowe wrote:
I'm getting more and more motivated to rewrite the vacuum docs. I
think a rewrite from the ground up might be best... I keep seeing
people doing vacuum full on this list and I'm thinking it's as much
because of the way the docs represent vacuum full as anything. Is
that t
On 9/12/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
>
> On 9/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Try a REINDEX. VACUUM FULL is especially hard on the indexes, and it's
> > > easy for them to seriously bloat.
> >
> > Reindex is done everyday after VACUUM FULL VERBOSE ANALYZE
On 9/12/07, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
>
> On 9/12/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> > On 9/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > > > Try a REINDEX. VACUUM FULL is especially hard on the indexes, and it's
> > > > easy for them to seriously bloat.
> >
On Sep 12, 2007, at 9:07 PM, Scott Marlowe wrote:
On 9/12/07, Mikko Partio <[EMAIL PROTECTED]> wrote:
…
Aren't you mixing up REINDEX and CLUSTER?
…
Either one does what a vacuum full did / does, but generally does
it better.
On topic of REINDEX / VACUUM FULL versus a CLUSTER / VACUUM ANALY
On 9/12/07, Frank Schoep <[EMAIL PROTECTED]> wrote:
> On Sep 12, 2007, at 9:07 PM, Scott Marlowe wrote:
> > On 9/12/07, Mikko Partio <[EMAIL PROTECTED]> wrote:
> >> …
> >> Aren't you mixing up REINDEX and CLUSTER?
> >
> > …
> > Either one does what a vacuum full did / does, but generally does
> > i
Scott Marlowe escribió:
> > Aren't you mixing up REINDEX and CLUSTER?
>
> I don't think so. reindex (which runs on tables and indexes, so the
> name is a bit confusing, I admit) basically was originally a "repair"
> operation that rewrote the whole relation and wasn't completely
> transaction sa
My PG server came to a screeching halt yesterday. Looking at top saw a very
large number of "startup waiting" tasks. A pg_dump was running and one of my
scripts had issued a CREATE DATABASE command. It looks like the CREATE DATABASE
was exclusive but was having to wait for the pg_dump to fin
On Sep 12, 2007, at 2:19 PM, Frank Schoep wrote:
On Sep 12, 2007, at 9:07 PM, Scott Marlowe wrote:
On 9/12/07, Mikko Partio <[EMAIL PROTECTED]> wrote:
…
Aren't you mixing up REINDEX and CLUSTER?
…
Either one does what a vacuum full did / does, but generally does
it better.
On topic of R
I'm designing a system that will be doing over a million inserts/deletes
on a single table every hour. Rather than using a single table, it is
possible for me to partition the data into multiple tables if I wanted
to, which would be nice because I can just truncate them when I don't
need the
On 9/12/07, Matt Chambers <[EMAIL PROTECTED]> wrote:
>
>
> I'm designing a system that will be doing over a million inserts/deletes on
> a single table every hour. Rather than using a single table, it is possible
> for me to partition the data into multiple tables if I wanted to, which
> would be
Dan Harris <[EMAIL PROTECTED]> writes:
> My PG server came to a screeching halt yesterday. Looking at top saw a very
> large number of "startup waiting" tasks. A pg_dump was running and one of
> my
> scripts had issued a CREATE DATABASE command. It looks like the CREATE
> DATABASE
> was ex
On Wed, 12 Sep 2007, Scott Marlowe wrote:
I'm getting more and more motivated to rewrite the vacuum docs. I think
a rewrite from the ground up might be best... I keep seeing people
doing vacuum full on this list and I'm thinking it's as much because of
the way the docs represent vacuum full
19 matches
Mail list logo
