Ok, I get that.

Really what I am *rooting* for is Aggregate (and Sort By) Push-Down to FDW 

I can already internalize conditional filters for most cases, and doing a count 
on the filtered results would be considerably faster in my FDW back-end before 
all the records and Datums have to be constructed for postgres to do the 

Similarly, I'm very excited about the potential for FDW to advertise a-priori 
sort states, so things like external merge-sorts can pass-through the request 
for sorted data for fields in which sorting is a no-op in my backend.

Importantly my IDs are sorted by definition since they are essentially array 
indexes into the column-store, so joining on them with merge-sort should be 
blazing fast, but currently time is wasted sorting these pre-sorted fields.

Just my 2c, and I'll be tracking the 9.6 progress that includes some of these 


-----Original Message-----
From: Tom Lane [mailto:t...@sss.pgh.pa.us] 
Sent: Thursday, February 25, 2016 11:21 PM
To: Gabe F. Rudy <r...@goldenhelix.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] FDW handling count(*) through AnalyzeForeignTable or 
other constant time push-down

"Gabe F. Rudy" <r...@goldenhelix.com> writes:
> Is there any way to convince Postgres FDW to leverage the analyze row counts 
> or even the "double* totalRowCount" returned from the AcquireSampleRows 
> callback from my AnalyzeForeignTable function so that it does not do a 
> full-table scan for a COUNT(*) etc?

No.  In PG's view, ANALYZE-based row counts are imprecise by definition.

                        regards, tom lane

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to