Re: sql/med review - problems with patching
От | Pavel Stehule |
---|---|
Тема | Re: sql/med review - problems with patching |
Дата | |
Msg-id | AANLkTin2yA6y8wA57GAwrfTkKbdqgC9b2pgFOHeBUbAy@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: sql/med review - problems with patching (Itagaki Takahiro <itagaki.takahiro@gmail.com>) |
Ответы |
Re: sql/med review - problems with patching
|
Список | pgsql-hackers |
2010/7/20 Itagaki Takahiro <itagaki.takahiro@gmail.com>: > 2010/7/14 Pavel Stehule <pavel.stehule@gmail.com>: >> please, can you refresh patch, please? > > Updated patch attached. The latest version is always in the git repo. > http://repo.or.cz/w/pgsql-fdw.git (branch: fdw) > I'm developing the patch on postgres' git repo. So, regression test > for dblink might fail because of out-of-sync issue between cvs and git. > >> When I looked to documentation I miss a some tutorial for foreign >> tables. There are only reference. I miss some paragraph where is >> cleanly and simple specified what is possible now and whot isn't >> possible. Enhancing of dblink isn't documented > > Sure. I'll start to write documentation when we agree the design of FDW. > >> In function pgIterate(ForeignScanState *scanstate) you are iterare >> via pg result. I am thinking so using a cursor and fetching multiple >> rows should be preferable. > > Sure, but I'm thinking that it will be improved after libpq supports > protocol-level cursor. The libpq improvement will be applied > much more applications including postgresql_fdw. > is there some time frame for this task - or ToDo point? Minimally it has to be documented, because it can be a issue on larger sets - speed, memory usage. I am afraid about speed for queries like select * from large_dblink_tab limit 100; Regards Pavel > -- > Itagaki Takahiro >
В списке pgsql-hackers по дате отправления: