Re: RE : RE: Postgresql vs SQLserver for this application ?
От | Mohan, Ross |
---|---|
Тема | Re: RE : RE: Postgresql vs SQLserver for this application ? |
Дата | |
Msg-id | CC74E7E10A8A054798B6611BD1FEF4D307966AEF@vamail01.thexchange.com обсуждение исходный текст |
Ответ на | RE : RE: Postgresql vs SQLserver for this application ? (bsimon@loxane.com) |
Список | pgsql-performance |
How close to this is PG's COPY? I get surprisingly good results using COPY with jdbc on smallish systems (now if that patchwould make into the mainstream PG jdbc support!) I think COPY has a bit more overhead than what a Bulkload featuremay have, but I suspect it's not that much more. || Steve, I do not know. But am reading the docs now, and should figure it out. Ask me later if you remember. Oracle's "direct path" is a way of just slamming blocks filled with rows into the table, above the high water mark. It sidesteps freelist management and all manner of intrablock issues. There is a "payback", but the benefits far far outweigh the costs. > Now...if you ask me "can this work without Power5 and Hitachi SAN?" my > answer is..you give me a top end Dell and SCSI III on 15K disks and > I'll likely easily match it, yea. > > I'd love to see PG get into this range..i am a big fan of PG (just a > rank newbie) but I gotta think the underlying code to do this has to > be not-too-complex..... It may not be that far off if you can use COPY instead of INSERT. But comparing Bulkload to INSERT is a bit apples<->orangish. || Oh! I see! I had no idea I was doing that! Thanks for pointing it out clearly to me. Yea, I would say a full transactional INSERT of 5K rows/sec into an indexed-table is a near-mythology without significant caveats (parallelized, deferred buffering, etc.) -- Steve Wampler -- swampler@noao.edu The gods that smiled on your birth are now laughing out loud.
В списке pgsql-performance по дате отправления: