From: | "Gabe F(dot) Rudy" <rudy(at)goldenhelix(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | FDW handling count(*) through AnalyzeForeignTable or other constant time push-down |
Date: | 2016-02-25 17:48:10 |
Message-ID: | SN1PR17MB033428EDC1DD6A65CFD818D5D4A60@SN1PR17MB0334.namprd17.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 in constant time the exact dimensions of the table.
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?
My current fallback is to export a specialized function that returns the table row count for a given FDW table, but that then leaks into the user-application driving these queries.
Thanks in advance!
Gabe
Gabe Rudy | VP Product & Engineering | Golden Helix, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2016-02-25 18:08:57 | Re: Performance degradation in commit 6150a1b0 |
Previous Message | Tomas Vondra | 2016-02-25 16:56:00 | Re: GIN data corruption bug(s) in 9.6devel |