remote database queries

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-interfaces by date

  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()