Re: Survey results from the PostgreSQL portal page
От | Curt Sampson |
---|---|
Тема | Re: Survey results from the PostgreSQL portal page |
Дата | |
Msg-id | Pine.NEB.4.51.0301232023040.335@angelic.cynic.net обсуждение исходный текст |
Ответ на | Re: Survey results from the PostgreSQL portal page (Hans-Jürgen Schönig <postgres@cybertec.at>) |
Список | pgsql-hackers |
On Sun, 19 Jan 2003, [ISO-8859-1] Hans-J\xFCrgen Sch\xF6nig wrote: > >+ people measure postgresql by the speed of bulk imports > > This is a good point. I can complete agree. What we might need is > something called "SQL Loader" or so. This may sound funny and it doesn't > make technical sense but it is an OBVIOUS way of importing data. People > often forget to use transactions or don't know about COPY. Even "doing it right," postgres 7.2 was significantly slower than MySQL for bulk data imports, at least for tables with relatively narrow rows. I was going to put this down to higher row overhead, except that it was nowhere near raw file I/O speed, either. So this could use improvement, if it's not been improved already. There's room for performance increases in a lot of other areas, too, but in the end, a lot of people just don't design their databases for good performance. And I've killed enough non-postgres database servers in my life to know that if you don't really know what you're doing, you can easily make the performance of any DBMS suck. :-) Personally, I think there's still a fair amount of room in the features area, too. I'm always running into something that I'd like to have. Today it was being able to defer a UNIQUE constraint. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
В списке pgsql-hackers по дате отправления: