Re: WIP: Collecting statistics on CSV file data

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marti Raudsepp <marti(at)juffo(dot)org>
Cc: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: Collecting statistics on CSV file data
Date: 2011-09-20 15:13:05
Message-ID: 8240.1316531585@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marti Raudsepp <marti(at)juffo(dot)org> writes:
> 2011/9/12 Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>:
>> This is called when ANALYZE command is executed. (ANALYZE
>> command should be executed because autovacuum does not analyze foreign
>> tables.)

> This is a good idea.

> However, if adding these statistics requires an explicit ANALYZE
> command, then we should also have a command for resetting the
> collected statistics -- to get it back into the un-analyzed state.

Uh, why? There is no UNANALYZE operation for ordinary tables, and
I've never heard anyone ask for one.

If you're desperate you could manually delete the relevant rows in
pg_statistic, a solution that would presumably work for foreign tables
too.

Probably a more interesting question is why we wouldn't change
autovacuum so that it calls this automatically for foreign tables.

(Note: I'm unconvinced that there's a use-case for this in the case of
"real" foreign tables on a remote server --- it seems likely that the
wrapper ought to ask the remote server for its current stats, instead.
But it's clearly useful for non-server-backed sources such as file_fdw.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira de Oliveira 2011-09-20 15:24:26 Re: WIP: Collecting statistics on CSV file data
Previous Message Dave Page 2011-09-20 15:03:00 Re: Back-branch releases upcoming this week