(2014/01/28 22:01), Etsuro Fujita wrote:
> (2014/01/27 21:49), Shigeru Hanada wrote:
>> Is it too big change that making ANALYZE command to handle foreign
>> tables too even if no table name was specified? IIRC, performance
>> issue was the reason to exclude foreign tables from auto-analyze
>> processing. ANALYZEing large database contains local huge data also
>> takes long time. One idea to avoid unexpected long processing is to
>> add option to foreign tables to mark it as "not-auto-analyzable".
>
> Maybe I didn't express my idea clearly. Sorry for that.
>
> I don't think that we now allow the ANALYZE command to handle foreign
> tables when no table name is specified with the command. I think that
> we allow the ANALYZE command to handle an inheritance tree that includes
> foreign tables when the name of the parent table is specified, without
> ignoring such foreign tables in the caluculation. ISTM it would be
> possible to do so if we introduce a new parameter, say, vac_mode, which
> indicates wether vacuum() is called with a specific table or not.
>
> I'll try to modify the ANALYZE command to do so on top of you patch.
Done on top of your patch, foreign_inherit.patch, not the latest
version, foreign_inherit-v2.patch. As I proposed, an inheritance tree
that includes foreign tables is now ANALYZEd, without ignoring such
foreign tables in the inherited-stats computation, if the name of the
parent table is specified with the ANALYZE command. (That has been done
by a small modification of analyze.c, thanks to [1].) The ANALYZE
command with no tablename or the autovacuum worker skips the
inherited-stats computation itself for inheritance trees that includes
foreign tables, which is different from the original patch. To
distinguish the ANALYZE-with-a-tablename command from the others (ie,
the ANALYZE-with-no-tablename command or the autovacuum worker), I've
introduced a new parameter, vacmode, in vacuum(), and thus called
analyze_rel() with that parameter. Attached is the modified patch.
Could you review the patch?
Thanks,
[1]
http://www.postgresql.org/message-id/E1SGFOO-0006ZF-8n@gemulon.postgresql.org
Best regards,
Etsuro Fujita