Re: Why Not MySQL?

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Mitch Vincent <mitch(at)huntsvilleal(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why Not MySQL?
Date: 2000-05-05 00:21:09
Message-ID: Pine.BSF.4.21.0005042120300.56194-100000@thelab.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 4 May 2000, Mitch Vincent wrote:

> > Well, drat. Looks like 7.0's query plan is slower :-(. There's
> > something fishy about the numbers for 6.5.3 though --- how could it have
> > done that query with zero blocks read? Are you sure you are comparing
> > apples to apples here? I wonder whether the 6.5 system already had the
> > tables cached in kernel disk buffers while 7.0 was working from a
> > standing start and had to physically go to the disk.
>
> This is very possible as the 6.5.3 PG is running on the production server
> which is constantly being queried.
>
> >Also, did both
> > versions have the same -B and -S settings?
>
> I didn't specify any -B or -S settings so both are using their respective
> defaults..

For you machine, go with something like '-S <32*1024>' to use 32Meg of RAM
for ORDER/GROUP BY ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 2000-05-05 00:38:12 RE: pg_group_name_index corrupt?
Previous Message The Hermit Hacker 2000-05-04 23:53:48 Re: pg_group_name_index corrupt?