On Monday, 4 February 2019 09:14:14 EET Vijaykumar Jain wrote:
> Hi,
Hi,
> with pg v10.1
> we use writes directly to shards, and reads via FDW from all shards (RO)
> our DB size is ~ 500GB each shard, and tables are huge too.
> 1 table ~ 200GB, 1 ~55GB, 1 ~40GB and a lot of small tables, but lar
Hi,
We'd like to configure an RDS server for shared hosting. The idea is that every
customer will be using a different database and FDW will be configured, so that
the remote tables have access to the full data, but materialized views will be
pulling from them data specific to each customer. So
Related to this question:
Postgresql cursors are in most cases I've tried extremely slow. The cause is as
described in my previous answer, in my experience. Is there any plan or way to
improve this situation? For example, for FDW one would expect the plan on the
remote side to be similar, if no
On Sunday, 17 February 2019 20:58:47 EET Jeff Janes wrote:
> A question for the PostgreSQL hackers would be, Is it necessary and
> desirable that the EXPLAIN be issued in the same transaction as the
> eventual DECLARE and FETCHes? I don't think it is. I guess if the foreign
> side table definitio
Hi,
One reason the remote plans via FDW are different than the plans of queries
running directly on the remote server is that a cursor is used, which is
optimized for low number of rows according to cursor_tuple_fraction. Is there
any way to set parameters that affect the queries on the remote
On Saturday, 18 January 2025 12:44:07 EET Alex Burkhart wrote:
> Hey team,
>
> I'm looking for help to organize locks and transaction for a reliable task
> queue.
>
> REQUIREMENTS
>
> 1. Pending actions are persisted to a database. There's a trace once they
> are done.
> 2. Application workers p
