BUG #15185: pg_dump doesn't include statistics when specifying a table

Started by PG Bug reporting formalmost 8 years ago2 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following bug has been logged on the website:

Bug reference: 15185
Logged by: Josha Foust
Email address: postgresql@lightn.org
PostgreSQL version: 10.3
Operating system: Windows
Description:

After using the CREATE STATISTICS command to create multi-column statistics
on a table, calling pg_dump with the -t option doesn't include that
definition, but it does include things like indexes.

I see this note in the documentation: "When -t is specified, pg_dump makes
no attempt to dump any other database objects that the selected table(s)
might depend upon. Therefore, there is no guarantee that the results of a
specific-table dump can be successfully restored by themselves into a clean
database." I don't think that applies here, but please tell me if I'm
wrong.

Here is a simple test case, created in a database named "test":

create table Events (
EventDt timestamp(6) with time zone not null,
EventId integer not null,
ProjectId smallint not null,
LoggerId integer,
Message text
);
create index IX_Events_ProjectId_LoggerId on Events (ProjectId, LoggerId);
create statistics Events_ProjectLogger (dependencies) ON ProjectId, LoggerId
FROM Events;

pg_dump.exe -U postgres --schema-only test
pg_dump.exe -U postgres -t public.events --schema-only test

The first pg_dump command output shows the "CREATE STATISTICS" line, while
the second one does not. It seems like it should.

#2Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: PG Bug reporting form (#1)
Re: BUG #15185: pg_dump doesn't include statistics when specifying a table

PG Bug reporting form wrote:

After using the CREATE STATISTICS command to create multi-column statistics
on a table, calling pg_dump with the -t option doesn't include that
definition, but it does include things like indexes.

I share your opinion that it should, but I was outvoted on that one and
didn't press any further. See
/messages/by-id/20180212150708.4vt2p2237fyh6bfx@alvherre.pgsql
for the old discussion.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services