Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGdyW-0005a6-Gv for pgsql-admin@arkaria.postgresql.org; Wed, 17 Apr 2019 06:23:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hGdyU-0007e8-8X for pgsql-admin@arkaria.postgresql.org; Wed, 17 Apr 2019 06:23:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGdyT-0007aK-QP for pgsql-admin@lists.postgresql.org; Wed, 17 Apr 2019 06:23:13 +0000 Received: from [195.159.176.226] (helo=blaine.gmane.org) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGdyQ-0001t7-Jg for pgsql-admin@postgresql.org; Wed, 17 Apr 2019 06:23:12 +0000 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hGdyN-000xGB-Q2 for pgsql-admin@postgresql.org; Wed, 17 Apr 2019 08:23:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-admin@postgresql.org From: Thomas Kellerer Subject: Re: Performance killed with FDW when using CAST. Date: Wed, 17 Apr 2019 08:23:02 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 In-Reply-To: Content-Language: de-DE X-Host-Lookup-Failed: Reverse DNS lookup failed for 195.159.176.226 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Laurenz Albe schrieb am 17.04.2019 um 07:03: >> We setup a FDW server for a large table that has an hstore data type as on eof the coums. >> >> When we run the query directly on the FDW server >> >> select * from recent_events where account_id = 1 AND (attributes -> 'account_incident_id')::integer = 2617116 limit 10; >> >> The response is 2ms . which is awesome. >> >> When we run it from the remote server where we have the server defined, the query never returns. >> >> Our server definition is as follows. >> >> (host 'fdwserver', dbname 'mydb', port '5432', fetch_size '1000', use_remote_estimate 'true', extensions 'hstore') > > After debugging into this, it seems that the hstore operator -> cannot > be pushed down because of collation problems. Do you happen to know if the JSONB operator -> (or ->>) can be pushed down? Although I realize it would be a major change in the database design, maybe that would be a solution for Jorge. Thomas