From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Statistics Import and Export |
Date: | 2023-08-31 07:07:12 |
Message-ID: | CAExHW5uRNe856LPYH1eZFyeASv4Xs4-9d1Gqj+rzS+3StVGLxQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 31, 2023 at 12:17 PM Corey Huinker <corey(dot)huinker(at)gmail(dot)com> wrote:
>
> While the primary purpose of the import function(s) are to reduce downtime
> during an upgrade, it is not hard to see that they could also be used to
> facilitate tuning and development operations, asking questions like "how might
> this query plan change if this table has 1000x rows in it?", without actually
> putting those rows into the table.
Thanks. I think this may be used with postgres_fdw to import
statistics directly from the foreigns server, whenever possible,
rather than fetching the rows and building it locally. If it's known
that the stats on foreign and local servers match for a foreign table,
we will be one step closer to accurately estimating the cost of a
foreign plan locally rather than through EXPLAIN.
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | torikoshia | 2023-08-31 07:47:21 | Re: Make --help output fit within 80 columns per line |
Previous Message | Ashutosh Bapat | 2023-08-31 06:55:17 | Re: persist logical slots to disk during shutdown checkpoint |