Skip site navigation (1) Skip section navigation (2)

Re: Fragmenting tables in postgres

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Karthik Guruswamy <karthikg(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fragmenting tables in postgres
Date: 2001-09-28 19:33:38
Message-ID: 200109281933.f8SJXcN13659@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> karthikg(at)yahoo(dot)com (Karthik Guruswamy) writes:
> > Anyone tried fragmenting tables into multiple sub tables 
> > transparently through Postgres rewrite rules ? I'm having 
> > a table with 200,000 rows with varchar columns and noticed 
> > that updates,inserts take a lot longer time compared to a 
> > few rows in the same table.
> 
> That's not a very big table ... there's no reason for inserts to
> take a long time, and not much reason for updates to take long either
> if you have appropriate indexes to help find the rows to be updated.
> Have you VACUUM ANALYZEd this table recently (or ever?)  Have you
> tried EXPLAINing the queries to see if they use indexes?
> 
> > I have a lot of memory in my 
> > machine like 2Gig and 600,000 buffers. 
> 
> You mean you set -B to 600000?  That's not a bright idea.  A few
> thousand will be plenty, and will probably perform lots better.

This is a good question.  When does too many buffers become a
performance problem?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-09-28 19:37:41
Subject: Re: pg_locale (Was: Re: Problem with setlocale (found in libecpg)...)
Previous:From: Bruce MomjianDate: 2001-09-28 19:21:24
Subject: Re: Spinlock performance improvement proposal

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group