Re: Thousands of tables versus on table?
От
Scott Marlowe
Тема
Re: Thousands of tables versus on table?
Дата
Msg-id
4666E5A0.40604@g2switchworks.com
Ответ на
Re: Thousands of tables versus on table? (Craig James)
Список
Дерево обсуждения
Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
Re: Thousands of tables versus on table? Mark Lewis <mark.lewis@mir3.com>
Re: Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
Re: Thousands of tables versus on table? Gregory Stark <stark@enterprisedb.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? david@lang.hm
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? Gregory Stark <stark@enterprisedb.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? david@lang.hm
Re: Thousands of tables versus on table? Tom Lane <tgl@sss.pgh.pa.us>
Re: Thousands of tables versus on table? "Steinar H. Gunderson" <sgunderson@bigfoot.com>
Re: Thousands of tables versus on table? Andrew Sullivan <ajs@crankycanuck.ca>
Re: Thousands of tables versus on table? david@lang.hm
Re: Thousands of tables versus on table? Heikki Linnakangas <heikki@enterprisedb.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? david@lang.hm
Re: Thousands of tables versus on table? Andrew Sullivan <ajs@crankycanuck.ca>
Re: Thousands of tables versus on table? "Jonah H. Harris" <jonah.harris@gmail.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? david@lang.hm
Re: Thousands of tables versus on table? Craig James <craig_james@emolecules.com>
Re: Thousands of tables versus on table? "Jonah H. Harris" <jonah.harris@gmail.com>
control of benchmarks (was: Thousands of tables) Andrew Sullivan <ajs@crankycanuck.ca>
Re: control of benchmarks (was: Thousands of tables) "Jonah H. Harris" <jonah.harris@gmail.com>
Re: Thousands of tables versus on table? Craig James <craig_james@emolecules.com>
Re: Thousands of tables versus on table? "Jonah H. Harris" <jonah.harris@gmail.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? Craig James <craig_james@emolecules.com>
Re: Thousands of tables versus on table? "Jonah H. Harris" <jonah.harris@gmail.com>
Re: Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
Re: Thousands of tables versus on table? Gregory Stark <stark@enterprisedb.com>
Re: Thousands of tables versus on table? "Y Sidhu" <ysidhu@gmail.com>
Re: Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
Re: Thousands of tables versus on table? PFC <lists@peufeu.com>
Re: Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
Craig James wrote: > > Oracle is simply not better than Postgres in this regard. As far as I > know, there is only one specific situation (discussed frequently here) > where Oracle is faster: the count(), min() and max() functions, and I > know significant progress has been made since I started using > Postgres. I have not found any other query where Oracle is > significantly better, and I've found several where Postgres is the > clear winner. In my testing between a commercial database that cannot be named and postgresql, I found max() / min() to be basically the same, even with where clauses and joins happening. count(*), OTOH, is a still a clear winner for the big commercial database. With smaller sets (1 Million or so) both dbs are in the same ballpark. With 30+million rows, count(*) took 2 minutes on pgsql and 4 seconds on the big database. OTOH, there are some things, like importing data, which are MUCH faster in pgsql than in the big database.
В списке pgsql-performance по дате отправления