Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 2772E1E08DB4 for ; Mon, 7 Nov 2011 07:27:04 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 49603-06 for ; Mon, 7 Nov 2011 11:26:53 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.216.174]) by mail.postgresql.org (Postfix) with ESMTP id 14CDA1E08DB6 for ; Mon, 7 Nov 2011 07:26:47 -0400 (AST) Received: by qyk27 with SMTP id 27so2223510qyk.19 for ; Mon, 07 Nov 2011 03:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lRNx91zMUf8XpX4Rucup9fixzkkEOUia5RzZJ8HnzDo=; b=fBUiHbqiQ7x2/+Q5Kwk4d24k5CnRLBpEe7//LcSViLmVrDDePUhqjvWjuwb80QYc3i ADFfE1XRM0hckS9cfFfblHUDzAMZRqaH1fEQwYtFnj6BEsiJyxIetKHcgKAuVBE7HgZ9 QHp70Xdk5lDpp5uz2fdQk+rKf6NlqKHaFaec8= Received: by 10.50.189.231 with SMTP id gl7mr44683274igc.44.1320665207058; Mon, 07 Nov 2011 03:26:47 -0800 (PST) Received: from [192.168.1.189] ([61.199.203.168]) by mx.google.com with ESMTPS id jm5sm35700540pbc.1.2011.11.07.03.26.45 (version=SSLv3 cipher=OTHER); Mon, 07 Nov 2011 03:26:46 -0800 (PST) Message-ID: <4EB7C07A.5030205@gmail.com> Date: Mon, 07 Nov 2011 20:26:50 +0900 From: Shigeru Hanada User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Etsuro Fujita CC: pgsql-hackers@postgresql.org Subject: Re: WIP: Collecting statistics on CSV file data References: <4E6DE18B.4010505@lab.ntt.co.jp> <4E7861C1.2000607@gmail.com> <4E8EC1D8.3080700@lab.ntt.co.jp> <4E9C6573.8050507@gmail.com> <4E9FF04B.3050504@lab.ntt.co.jp> In-Reply-To: <4E9FF04B.3050504@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.899 tagged_above=-5 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001 X-Spam-Level: X-Archive-Number: 201111/319 X-Sequence-Number: 197810 (2011/10/20 18:56), Etsuro Fujita wrote: > I revised the patch according to Hanada-san's comments. Attached is the > updated version of the patch. > > Changes: > > * pull up of logging "analyzing foo.bar" > * new vac_update_relstats always called > * tab-completion in psql > * add "foreign tables are not analyzed automatically..." to 23.1.3 > Updating Planner Statistics > * some other modifications Submission review ================= - Patch can be applied, and all regression tests passed. :) Random comments =============== - Some headers are not necessary for file_fdw.c #include "access/htup.h" #include "commands/dbcommands.h" #include "optimizer/plancat.h" #include "utils/elog.h" #include "utils/guc.h" #include "utils/lsyscache.h" #include "utils/rel.h" - It might be better to mention in document that users need to explicitly specify foreign table name to ANALYZE command. - I think backend should be aware the case which a handler is NULL. For the case of ANALYZE of foreign table, it would be worth telling user that request was not accomplished. - file_fdw_do_analyze_rel is almost copy of do_analyze_rel. IIUC, difference against do_analyze_rel are: * don't logging analyze target * don't switch userid to the owner of target table * don't measure elapsed time for autoanalyze deamon * don't handle index * some comments are removed. * sample rows are acquired by file_fdw's routine I don't see any problem here, but would you confirm that all of them are intentional? Besides, keeping format (mainly indent and folding) of this function similar to do_analyze_rel would help to follow changes in do_analyze_rel. - IMHO exporting CopyState should be avoided. One possible idea is adding new COPY API which allows to extract records from the file with skipping specified number or rate. - In your design, each FDW have to copy most of do_analyze_rel to their own source. It means that FDW authors must know much details of ANALYZE to implement ANALYZE handler. Actually, your patch exports some static functions from analyze.c. Have you considered hooking acquire_sample_rows()? Such handler should be more simple, and FDW-specific. As you say, such design requires FDWs to skip some records, but it would be difficult for some FDW (e.g. twitter_fdw) which can't pick sample data up easily. IMHO such problem *must* be solved by FDW itself. -- Shigeru Hanada