remote database queries - Mailing list pgsql-hackers

From Joe Conway
Subject remote database queries
Date
Msg-id 009101c0e98e$872bdb00$0205a8c0@jecw2k1
Whole thread Raw
In response to Re: [INTERFACES] remote database queries  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: remote database queries  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: remote database queries  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: "Valentin Puente"
Date:
Subject: Question about scalability in postgresql 7.1.2
Next
From: chris.bitmead@health.gov.au
Date:
Subject: Re: Question about inheritance