Any functional code to be tested to confirm?
Regards,
David
On Fri, 21 Jan 2022 at 15:55, Laurenz Albe wrote:
> On Fri, 2022-01-21 at 14:33 +, Duarte Carreira wrote:
> > If we just create the 2 foreign tables, one complete and one without id,
> > you can simply insert into the table withou
On Fri, 2022-01-21 at 14:33 +, Duarte Carreira wrote:
> If we just create the 2 foreign tables, one complete and one without id,
> you can simply insert into the table without id and it will work fine.
> To select and show data, you use the "complete" table that has the id column.
>
> No need
Hmmm... I don't think a view or trigger are necessary.
If we just create the 2 foreign tables, one complete and one without id,
you can simply insert into the table without id and it will work fine.
To select and show data, you use the "complete" table that has the id
column.
No need for trigger
On Thu, 2022-01-20 at 15:59 +, Duarte Carreira wrote:
> I got here after encountering the same difficulty, although on a much more
> mundane scenario.
>
> I'm used to fdw on a read-only basis. I was just inserting a new record on a
> foreign table
> and got blocked... and after much searchin
Thanks for your help!
I'm not going forward with the id generating scheme... I prefer to let the
bd do that work on its own. Sharding is way over my head.
For now I just created the 2 tables, one for inserting (without the id
column), another for everything else. It's awkward and prone to human er
On Thu, 20 Jan 2022 at 21:29, Duarte Carreira wrote:
> Hello everyone.
>
> I don't know... realistically what do you guys see as a best/simple
> approach?
>
We implemented a custom sharding (directory sharding with lookup tables)
layer of 10 shards, but it was write local, read global.
the api w
Hello everyone.
I got here after encountering the same difficulty, although on a much more
mundane scenario.
I'm used to fdw on a read-only basis. I was just inserting a new record on
a foreign table and got blocked... and after much searching got here.
Not to rant or anything, but I am complete
You are right, we added more than one
coordinator nodes for high availability and to avoid single point of
failure.
Thanks
Swathi
On Tue, Jun 1, 2021, 3:54 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Tue, Jun 1, 2021 at 3:31 PM Etsuro Fujita
> wrote:
> >
> > Hi,
>
On Tue, Jun 1, 2021 at 3:31 PM Etsuro Fujita wrote:
>
> Hi,
>
> On Fri, May 14, 2021 at 6:08 PM Swathi P wrote:
> > In our sharding solution, we have multiple coodinator nodes. If we declare
> > the table column as serial data type, we might end up having duplicate
> > values for id column in t
Hi,
On Fri, May 14, 2021 at 6:08 PM Swathi P wrote:
> In our sharding solution, we have multiple coodinator nodes. If we declare
> the table column as serial data type, we might end up having duplicate values
> for id column in the table_a in host_b (data node) as cconnections come from
> mult
On Fri, 2021-05-14 at 10:53 -0400, Tom Lane wrote:
> Swathi P writes:
> > Hence we decided to have the coordinator nodes as stateless and hence
> > declared the column with no serial/sequence. Let me know if this makes
> > sense.
>
> Attaching serial-sequence defaults on both sides would certainl
Bharath Rupireddy writes:
> On Fri, May 14, 2021 at 8:23 PM Tom Lane wrote:
>> One conceivable workaround is to do your insertions through a
>> foreign table that doesn't even have the serial column, so that
>> the INSERT command received by the remote server lacks that
>> column and the default
On Fri, May 14, 2021 at 8:23 PM Tom Lane wrote:
>
> [ removing -bugs ]
>
> Swathi P writes:
> > Hence we decided to have the coordinator nodes as stateless and hence
> > declared the column with no serial/sequence. Let me know if this makes
> > sense.
>
> Attaching serial-sequence defaults on bot
On Fri, May 14, 2021 at 12:37 PM Swathi P wrote:
>
> Thanks Bharath for the details.
>
> In our sharding solution, we have multiple coodinator nodes. If we declare
> the table column as serial data type, we might end up having duplicate values
> for id column in the table_a in host_b (data node)
[ removing -bugs ]
Swathi P writes:
> Hence we decided to have the coordinator nodes as stateless and hence
> declared the column with no serial/sequence. Let me know if this makes
> sense.
Attaching serial-sequence defaults on both sides would certainly not
work very well, because the sequences
Thanks Bharath for the details.
In our sharding solution, we have multiple coodinator nodes. If we declare
the table column as serial data type, we might end up having duplicate
values for id column in the table_a in host_b (data node) as cconnections
come from multiple coordinatoor nodes and migh
On Thu, May 13, 2021 at 4:58 PM Swathi P wrote:
>
> Hello EveryOne,
>
> Hope you are all doing well and staying safe.
>
> Am Swathi, have been working with postgres for last 3 years. Currently we are
> working on a project to build a sharding solution with the help of native
> postgres_fdw exte
17 matches
Mail list logo
