Search Postgresql Archives

Re: [External] Re: FDW, too long to run explain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ok.
I’ll try to work on it this week and see if i am able to reproduce anything.

On Mon, 18 Feb 2019 at 2:30 AM Jeff Janes <jeff.janes@xxxxxxxxx> wrote:


On Sun, Feb 17, 2019 at 2:37 PM Vijaykumar Jain <vjain@xxxxxxxxxxxxx> wrote:

Ok, i raked this from the logs where enabled log_min_duration_statement = 10s

2019-01-31 12:48:18 UTC LOG:  duration: 29863.311 ms  statement: EXPLAIN SELECT blah, FROM public.view WHERE ((scheduled_bdt >= '2019-01-20'::date)) AND ((scheduled_bdt <= '2019-01-26'::date)) AND ((somekey = ANY ('{269029,123399,263164,261487}'::bigint[])))   (both the columns are indexed)

That is interesting.  Was that in the logs for the local or the foreign side?  And is it common, or rare?

If on the local side, could it be that the EXPLAINs sent to the foreign side are being made to wait by the connection pooler, leading to long delays?  If that is from the foreign side, then it should be conceptually unrelated to FDW.  Any chance you could reproduce the slowness in your test environment?  Slowness in the planner is probably related to the schema structure, not the data itself.

I don't think this would be related to the idle-in-transaction, except that one FDW connection maybe idle-in-transaction after its EXPLAIN is done because it is waiting for another FDW connection to slowly run its EXPLAIN.

Cheers,

Jeff
--

Regards,
Vijay

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux