From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Maarten Boekhold <maarten(dot)boekhold(at)tibcofinance(dot)com> |
Cc: | "Brett W(dot) McCoy" <bmccoy(at)chapelperilous(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: full-text indexing |
Date: | 2000-04-20 13:56:48 |
Message-ID: | 200004201356.JAA26043@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Hi,
>
> I guess that 'original author' would be me....
Yes.
>
> > > With the original author, testing was fast, but when he loaded all the
> > > data, it got very slow. The problem was that as soon as his data
> > > exceeded the buffer cache, performance became terrible.
> >
> > How much data are we talking here? How can one get around this buffer
> > cache problem?
>
> This is all from head, but if I remember correctly, the main table had about
> 750.000 rows, of which one varchar(25) field was fti'ed ('full text indexed'
> :),
> resulting in some 5 million rows in the fti table.
>
> wrt file sizes, I don't really remember. If you're really interested, I can
> make another setup to check this (over easter time).
>
> I'm curious: Bruce mentioned buffer cache sizes. What exactly is this buffer
> cache
> used for? I thought we relied on the OS filesystem caching to cache database
> files?
> What will increasing buffer caches give me?
The PostgreSQL shared buffers are used by the database to read/write 8k
db buffers. The OS has buffers two, so there is some duplication. Ours
exist in shared memory so all backends can use the information and
mark/flush them as needed. Increasing the shared buffer cache will keep
more buffers availible, but frankly the OS buffer cache is just/more
important. It is when the stuff is in neither cache and we have to go
to disk thousands of time for one query that things get bad.
--
Bruce Momjian | http://www.op.net/~candle
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alfred Perlstein | 2000-04-20 16:26:15 | automatic crash recovery |
Previous Message | Hentosh | 2000-04-20 11:25:39 | RE: Full text indexing. |