remote database queries
| От | Joe Conway |
|---|---|
| Тема | remote database queries |
| Дата | |
| Msg-id | 009101c0e98e$872bdb00$0205a8c0@jecw2k1 обсуждение исходный текст |
| Ответ на | Re: [INTERFACES] remote database queries (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: remote database queries
Re: remote database queries |
| Список | pgsql-hackers |
> Until we fix that (maybe for 7.2, maybe not) your existing hack is > probably pretty reasonable. You could save some cycles by avoiding > conversion to text, though --- instead return an opaque datum that is > pointer-to-tuple-slot and let the dblink_tok function extract fields > from the tuple. Look at SQL function support and the FieldSelect > expression node type for inspiration. > I changed the dblink() function to return a pointer instead of concatenated text, and dblink_tok() to use the pointer. FWIW, a query on a small (85 tuples) remote (a second PC on a 100baseT subnet) table takes about 34 milliseconds (based on show_query_stats) versus about 4 milliseconds when run locally. It actually takes a bit longer (~65 milliseconds) when run against a second database on the same PC. The original text parsing version was about 25% slower. Although shifting from text parsing to pointer passing is more efficient, I have one more question regarding this -- for now ;) -- is there any way to check the pointer passed to dblink_tok() to be sure it came from dblink()? Thanks, -- Joe
В списке pgsql-hackers по дате отправления: