proposals.
Gabe
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, February 25, 2016 11:21 PM
To: Gabe F. Rudy
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] FDW handling count(*) through AnalyzeForeignTable or
other constant time push-down
&qu
On 25 February 2016 at 09:48, Gabe F. Rudy wrote:
> Hey all,
>
>
>
> I’m building a FDW around a column-store backend (similar to CStore but
> for genomic data!).
>
>
>
> I have tables in the billions of rows, and have a common query pattern of
> asking for the table size (i.e. SELECT COUNT(*) FR
"Gabe F. Rudy" 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
Hey all,
I'm building a FDW around a column-store backend (similar to CStore but for
genomic data!).
I have tables in the billions of rows, and have a common query pattern of
asking for the table size (i.e. SELECT COUNT(*) FROM big_fdw_table; ).
This is a read-optimized system in which I know
