Re: FDW handling count(*) through AnalyzeForeignTable or other constant time push-down

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: "Gabe F(dot) Rudy" <rudy(at)goldenhelix(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FDW handling count(*) through AnalyzeForeignTable or other constant time push-down
Date: 2016-02-26 16:06:34
Message-ID: CANP8+jKmtZMgrvT6Bshz8i+QY-8iCdq0VJ_d4y0U37LQdy7T6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 25 February 2016 at 09:48, Gabe F. Rudy <rudy(at)goldenhelix(dot)com> 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(*) 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.
>

Look at TABLESAMPLE, which does mostly what you're asking.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-02-26 16:06:36 Re: The plan for FDW-based sharding
Previous Message Alvaro Herrera 2016-02-26 16:02:04 Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.