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

Поиск
Список
Период
Сортировка
От Gabe F. Rudy
Тема FDW handling count(*) through AnalyzeForeignTable or other constant time push-down
Дата
Msg-id SN1PR17MB033428EDC1DD6A65CFD818D5D4A60@SN1PR17MB0334.namprd17.prod.outlook.com
обсуждение исходный текст
Ответы Re: FDW handling count(*) through AnalyzeForeignTable or other constant time push-down  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: FDW handling count(*) through AnalyzeForeignTable or other constant time push-down  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
<div class="WordSection1"><p class="MsoNormal">Hey all,<p class="MsoNormal"> <p class="MsoNormal">I’m building a FDW
arounda column-store backend (similar to CStore but for genomic data!).<p class="MsoNormal"> <p class="MsoNormal">I
havetables in the billions of rows, and have a common query pattern of asking for the table size (i.e. SELECT COUNT(*)
FROMbig_fdw_table; ).<p class="MsoNormal"> <p class="MsoNormal">This is a read-optimized system in which I know in
constanttime the exact dimensions of the table.<p class="MsoNormal"> <p class="MsoNormal">Is there any way to convince
PostgresFDW to leverage the analyze row counts or even the “double* totalRowCount” returned from the AcquireSampleRows
callbackfrom my AnalyzeForeignTable function so that it does not do a full-table scan for a COUNT(*) etc?<p
class="MsoNormal"> <pclass="MsoNormal">My current fallback is to export a specialized function that returns the table
rowcount for a given FDW table, but that then leaks into the user-application driving these queries.<p
class="MsoNormal"> <pclass="MsoNormal">Thanks in advance!<p class="MsoNormal">Gabe<p class="MsoNormal"> <p
class="MsoNormal"style="background:white"><b><span style="font-size:10.0pt;color:#262626">Gabe Rudy</span></b><span
style="font-size:10.0pt;color:#595959">| VP Product & Engineering | Golden Helix, Inc.</span><span
style="color:black"></span><pclass="MsoNormal"> </div> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: GIN data corruption bug(s) in 9.6devel
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Performance degradation in commit 6150a1b0