Re: Joel's Performance Issues WAS : Opteron vs Xeon

Поиск
Список
Период
Сортировка
От Joel Fradkin
Тема Re: Joel's Performance Issues WAS : Opteron vs Xeon
Дата
Msg-id 001901c54608$b70ccfc0$797ba8c0@jfradkin
обсуждение исходный текст
Ответ на Re: Joel's Performance Issues WAS : Opteron vs Xeon  (John A Meinel <john@arbash-meinel.com>)
Ответы Re: Joel's Performance Issues WAS : Opteron vs Xeon
Re: Joel's Performance Issues WAS : Opteron vs Xeon
Re: Joel's Performance Issues WAS : Opteron vs Xeon
Список pgsql-performance
I did think of something similar just loading the data tables with junk
records and I may visit that idea with Josh.

I did just do some comparisons on timing of a plain select * from tbl where
indexed column = x and it was considerably slower then both MSSQL and MYSQL,
so I am still a bit confused. This still might be configuration issue (I ran
on my 2gig desktop and the 8 gig Linux box comparisons were all ran on the
same machines as far MSSQL, MYSQL, and Postgres.
I turned off postgres when running MYSQL and turned off MYSQL when running
postgres, MSSQL had one of the two running while I tested it.

For the 360,000 records returned MYSQL did it in 40 seconds first run and 17
seconds second run.

MSSQL did it in 56 seconds first run and 16 seconds second run.

Postgres was on the second run
Total query runtime: 17109 ms.
Data retrieval runtime: 72188 ms.
331640 rows retrieved.

So like 89 on the second run.
The first run was 147 secs all told.

These are all on my 2 meg desktop running XP.
I can post the config. I noticed the postgres was using 70% of the cpu while
MSSQL was 100%.

Joel Fradkin


>I would of spent more $ with Command, but he does need my data base to help
>me and I am not able to do that.
>
>
...

What if someone were to write an anonymization script. Something that
changes any of the "data" of the database, but leaves all of the
relational information. It could turn all strings into some sort of
hashed version, so you don't give out any identifiable information.
It could even modify relational entries, as long as it updated both
ends, and this didn't affect the actual performance at all.

I don't think this would be very hard to write. Especially if you can
give a list of the tables, and what columns need to be modified.

Probably this would generally be a useful script to have for cases like
this where databases are confidential, but need to be tuned by someone else.

Would that be reasonable?
I would think that by renaming columns, hashing the data in the columns,
and renaming tables, most of the proprietary information is removed,
without removing the database information.

John
=:->



В списке pgsql-performance по дате отправления:

Предыдущее
От: John A Meinel
Дата:
Сообщение: Re: postgres slowdown question
Следующее
От: John A Meinel
Дата:
Сообщение: Re: Joel's Performance Issues WAS : Opteron vs Xeon