Re: [HACKERS] 8.2 features?
От | Joe Conway |
---|---|
Тема | Re: [HACKERS] 8.2 features? |
Дата | |
Msg-id | 44CE529F.2070701@joeconway.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] 8.2 features? (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [HACKERS] 8.2 features?
Re: [HACKERS] 8.2 features? |
Список | pgsql-patches |
Tom Lane wrote: > As far as avoiding overhead goes, here's what I'm thinking: > > * The Values RTE node should contain a list of lists of bare > expressions, without TargetEntry decoration (you probably do not > need ResTarget in the raw parse tree for VALUES, either). > > * The ValuesScan plan node will just reference this list-of-lists > (avoiding making a copy). It will need to contain a targetlist > because all plan nodes do, but the base version of that will just > be a trivial "Var 1", "Var 2", etc. (The planner might replace that > with a nontrivial targetlist in cases such as the example above.) I wanted to post an updated patch even though there are still things not working again after conversion to bare expressions. Note that I hacked enough of the executor stuff so I could test my changes on the parser area. The basic "INSERT ... VALUES (...), (...), ..." does work, but without DEFAULT again :-(. The good news is that from a memory and perfomance standpoint, my simple test now shows us outperforming mysql: $loopcount = 1000000; Postgres: multi-INSERT-at-once Elapsed time is 12 seconds ~420MB MySQL: multi-INSERT-at-once Elapsed time is 17 seconds ~600MB $loopcount = 2000000; Postgres: multi-INSERT-at-once Elapsed time is 29 seconds ~730MB MySQL: multi-INSERT-at-once Elapsed time is 37 seconds ~1.2GB (this one is from memory -- I didn't write it in my notes) Joe
Вложения
В списке pgsql-patches по дате отправления: