Re: Statistics Import and Export - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Statistics Import and Export
Date
Msg-id CADkLM=fz7RBQegDT_a+vXZ58PHEKZ-XrrjGK3JkSBnzKGWz3bw@mail.gmail.com
Whole thread Raw
In response to Re: Statistics Import and Export  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Statistics Import and Export
List pgsql-hackers
Note that there's two different things we're talking about here- the
lock on the relation that we're analyzing and then the lock on the
pg_statistic (or pg_class) catalog itself.  Currently, at least, it
looks like in the three places in the backend that we open
StatisticRelationId, we release the lock when we close it rather than
waiting for transaction end.  I'd be inclined to keep it that way in
these functions also.  I doubt that one lock will end up causing much in
the way of issues to acquire/release it multiple times and it would keep
the code consistent with the way ANALYZE works.

ANALYZE takes out one lock StatisticRelationId per relation, not per attribute like we do now. If we didn't release the lock after every attribute, and we only called the function outside of a larger transaction (as we plan to do with pg_restore) then that is the closest we're going to get to being consistent with ANALYZE.

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Vectored I/O in bulk_write.c
Next
From: Thomas Munro
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring