> > Very interesting. Is it possible to get the schema, the query, and a
> > a sample of the data or a generator program for the data? I am quite surprised
> > to see us do so well, I would have guess that the per row overhead would
> > have us down far below wc.
>
> Sure.
>
> create table test (x1 int, x2 int, x3 char(10), x4 varchar(50));
> insert into test values (3, 8, 'asdf','asdf');
>
> insert into test select * from test; <- continue until test is large
>
> select * from test where x1 = 23423; <- this is what I timed
>
So I finally got around to playing with this a little and I get on my
P133 (HX mb) 32 Mb mem, Linux 2.0.32 (glibc) with Quantum Atlas 2.1G disk
on NCR810 SCSI
for test at 1048576 rows, file size is 80281600 bytes.
- time cat pg/test/data/base/dg/test >/dev/null
0.02user 3.38system 0:14.34elapsed 23%CPU = 5467 KB per second.
- time wc pg/test/data/base/dg/test
9.12user 2.83system 0:15.38elapsed 77%CPU = 5098 KB per second.
- time psql -c "select * from test where x1 = 23423;"
0:30.59elapsed (cpu for psql not meaningful, but top said 95% for postgres)
= 2563 KB per second.
Not bad!
- time psql -c "select count(*) from test;"
0:50.46elapsed = 1554 KB per second.
(trivial aggragate adds 20 seconds or 65%)
- time psql -c "select count(*) from test where x1 = 3;"
1:03.22elapsed = 1240 KB per second.
(trivial where clause adds another 13 seconds)
- time psql -c "select count(*) from test where x4 = 'asdf';"
1:10.96elapsed = 1105 KB per second.
(varchar compare vs int compare adds only 7.7 seconds).
Btw, during all this, the disk hardly even made any noise (seeking).
ext2 seems to lay things out pretty well. The data dir right now is on a
/home, which is 86% full and it still managed to stream the 'cat' at about
full disk bandwidth.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
"I believe OS/2 is destined to be the most important operating
system, and possibly program, of all time" - Bill Gates, Nov, 1987.
