Thread

  1. Re: your mail

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-10T22:20:51Z

    > 
    > For each test, I will list 2 numbers here, the first being with the default
    > number of buffers, the second with 256 buffers (ie. 2048K)
    > 
    > btw. just to give all possible information: I start postgreSQL with the
    > following arguments:
    > 
    > -i -b /usr/local/pgsql/bin/postgres -S 1024 -o "-o mylogfile -F -d 1"
    > 
    > > OK, I meant to reply to this, but forgot to.  Let's take the second query:
    > >
    > >	select count(*) from artist_fti where string ~ '^lling';
    > >
    > > Have you tried adding -B buffers.  This, I think, would help.  If you
    > > don't flush the cache, how long does a second identical query take? 
    > 
    > This is 3 times the above query without trashing in between and with
    > the default number of buffers:
    > 
    > 	0.030u 0.020s 0:23.41 0.2% 0+0k 0+0io 201pf+0
    > 	0.040u 0.010s 0:01.06 4.7% 0+0k 0+0io 184pf+0w
    > 	0.030u 0.040s 0:00.70 10.0% 0+0k 0+0io 184pf+0w
    
    OK, I think this actually tells the whole story.  The query goes from 22
    seconds to 0.75 seconds because all of the btree indexes are in the
    buffer.   Looks like the optimizer is clearly understanding both parts
    of the restriction, which is good.  No problems there.
    
    Also seems the index fits easily in the cache.
    
    Now my question is "What is the performance problem?"  Doesn't the
    shared buffer cache keep these in memory, so the first one is slow, but
    the rest are fast, or does the buffer get flushed a lot, and performance
    is terrible on the first query after that.  Does going after other words
    flush the cache for previous words searched?
    
    I must say, I am surprised that the buffer cache causes it to speed up
    so much.  Are these really slow disks?
    
    In the Ingres case, the first query or two was not as quick, but they
    speeded up, and kept pretty fast for the rest of the day.  Also, the
    indexes where ISAM, which has a less sophisticated/less overhead way of
    indexing than btree.
    
    
    -- 
    Bruce Momjian                          |  830 Blythe Avenue
    maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
      +  If your life is a hard drive,     |  (610) 353-9879(w)
      +  Christ can be your backup.        |  (610) 853-3000(h)