Hi all,
I want to share with you an interesting experience I just had.
I did the following SELECT:
SELECT ip_dst,SUM(bytes),SUM(packets),SUM(flows) FROM
tcom_v5_20060530 WHERE stamp_inserted='2006-05-30 00:00:00' AND
stamp_inserted'2006-05-30 02:00:00' AND port_src='53' AND
port_dst='53' AND
On Wed 31 May 2006 19:23, Sven Anderson wrote:
Hi all,
I want to share with you an interesting experience I just had.
I did the following SELECT:
SELECT ip_dst,SUM(bytes),SUM(packets),SUM(flows) FROM
tcom_v5_20060530 WHERE stamp_inserted='2006-05-30 00:00:00' AND
stamp_inserted'2006-05-30
Hi Wim,
Wim Kerkhoff, 04.05.2006 06:09:
Disabling fsync() does improve performance. I did this once for a Pmacct
database, but was bitten horribly after the server was rebooted a couple
of times without being shutdown properly (power/UPS failure etc). So
don't do that.
You mean: all the
Hi Paolo,
Paolo Lucente, 01.05.2006 17:20:
it seems to be known, that a default MySQL performs a lot better than a
default PostgreSQL. One difference is, that PostgreSQL is doing an COMMIT
Not to open a possible flame, but i fully agree with this view. However, we
massively deal with
Sven Anderson wrote:
Hi all,
Sven Anderson, 21.04.2006 21:34:
I think the problem is not the updating of the data itself, but updating
the complex primary key. An index of (ip_src, ip_dst, stamp_inserted) is
fast enough to find entries, and easy enough to maintain.
it seems to be
Hey Sven,
On Fri, Apr 28, 2006 at 02:31:43PM +0200, Sven Anderson wrote:
it seems to be known, that a default MySQL performs a lot better than a
default PostgreSQL. One difference is, that PostgreSQL is doing an COMMIT
Not to open a possible flame, but i fully agree with this view. However,
Hi all,
Sven Anderson, 21.04.2006 21:34:
I think the problem is not the updating of the data itself, but updating
the complex primary key. An index of (ip_src, ip_dst, stamp_inserted) is
fast enough to find entries, and easy enough to maintain.
it seems to be known, that a default MySQL
Hi Paolo and all,
Paolo Lucente, 10.04.2006 18:42:
digging through the SQL scripts i've just noticed something bad: primary
keys of default PostgreSQL tables v2-v5 are just missing the 'vlan' field
(while it correctly appears in equivalent MySQL/SQLite 3.x schemas).
This may explain the
This one time, at band camp, Sven Anderson wrote:
Hi,
i'm just testing pmacct on OpenBSD 3.7. First I used MySQL as data
backend. Even after several days of capturing into the same table I had no
performance problems. But since the MySQL backend uses a string for
ip_proto and has no IP address
Hi Aaron and all,
thank you for your reply.
Aaron Glenn, 08.04.2006 01:50:
It could be a myriad of issues. Have you changed any of the default
PostgreSQL settings? PostgreSQL, by default, is not configured for
anything but pure compatibility - meaning it will certainly work, but
not at it's
Hey Sven,
digging through the SQL scripts i've just noticed something bad: primary
keys of default PostgreSQL tables v2-v5 are just missing the 'vlan' field
(while it correctly appears in equivalent MySQL/SQLite 3.x schemas).
This may explain the slowness. To verify this, can you please modify the
On 4/7/06, Sven Anderson [EMAIL PROTECTED] wrote:
Is there a tuning problem, or is PostgreSQL known to be not as fast as
MySQL? I thought, maybe there are some kind of rollback journals written,
which MySQL doesn't, or the hash-tables are not indexed correctly? Any ideas?
It could be a myriad
12 matches
Mail list logo
