All of the below, with minor changes has been checked in.... please let
me know if it broke anything...
> From: Michael Stone <mstone@...>
> To: Kevin Johnson <kjohnson@...>
> Subject: more patches
> Date: Fri, 08 Apr 2005 17:45:02 -0400
> Two patches. The first corrects a bug which prevents the
> $refresh_stat_page option from having an affect on the alert screen. The
> second is a performance patch which does three things:
> 1. Adds an avoid_counts option to minimize the use of count(*). On
> postgres count(*) always triggers a sequential scan, which is a killer
> on a large database. mysql stores the row count for the table and can
> return a count(*) in constant time, so it wouldn't get a big boost out
> of this option. For reference, a 10M row postgres database takes about
> 45s to return count(*) on my test platform.
> 2. Adds a show_first_last_links option which determines whether the
> first & last timestamps on the alert screen are clickable links.
> Disabling this causes a fairly large performance boost on a large
> database. For reference, on a 3M row mysql database this option reduces
> the alert screen load time for "last 24 hours" alerts from 43s to 3s.
> 3. Removes the tcp/udp/icmp/scan display from the main screen if the
> show_stats option is disabled. This is another one that takes a long
> time on a large database, and isn't generally all that interesting in
> that case anyway.=20
> I'm working on a couple of more tweaks, including a schema change, to
> speed postgres up a bit more. There seems to be a crossover point where
> postgres is actually faster than mysql on indexed queries once the db
> gets large enough, probably due to the postgres' better query planner.
> Of course I'll have to run all the numbers again for mysql5. :)=20
> Mike Stone
Get latest updates about Open Source Projects, Conferences and News.