From: | "Joe Conway" <joe(dot)conway(at)mail(dot)com> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | remote database queries |
Date: | 2001-05-31 04:59:52 |
Message-ID: | 009101c0e98e$872bdb00$0205a8c0@jecw2k1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-interfaces |
> 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 | Content-Type | Size |
---|---|---|
dblink.patch | application/octet-stream | 15.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-31 05:09:05 | Re: Imperfect solutions |
Previous Message | Christopher Kings-Lynne | 2001-05-31 04:12:38 | RE: Imperfect solutions |
From | Date | Subject | |
---|---|---|---|
Next Message | Manika dey | 2001-05-31 14:31:39 | Re: Using BLOBs with several DBMS |
Previous Message | Bruce Momjian | 2001-05-30 16:34:53 | Re: [JDBC] Re: Trouble with JDBC2 ResultSet.getDate() |