Re: remote database queries
От | Bruce Momjian |
---|---|
Тема | Re: remote database queries |
Дата | |
Msg-id | 200106141648.f5EGmlF09097@candle.pha.pa.us обсуждение исходный текст |
Ответ на | remote database queries ("Joe Conway" <joe.conway@mail.com>) |
Список | pgsql-hackers |
Added to /contrib. Thanks. > > 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 > [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: