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
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? |