On 22.04.20 21:10, Christian Ramseyer wrote:
>
> I see that in pgjdbc there are additional options for targetServerType =
> any, primary, secondary, preferSlave and preferSecondary[2]. However
> this seems to be java-specific and not implemented in libpq? Is there a
> way to get this behaviour in
On 2020-04-22 10:00:49 +0200, PALAYRET Jacques wrote:
> From a table x(c1) containing 30 lines with integer values (column c1) from 1
> to 30 :
>
> SELECT percentile_cont(1./3) WITHIN GROUP (ORDER BY c1) FROM x ;
> percentile_cont
> --
> 10.7
> (1 ligne)
> SELECT perc
On 2020-04-21 21:16:57 +, Kevin Brannen wrote:
> From: Michael Loftis
> > drbdsetup allows you to control the sync rates.
>
> I was hoping not to have to do that, but the more I think about this I'm
> realizing that it won't hurt because the network cap is effectively limiting
> me
> anyway.
What you need is async replication instead of synchronous replication.
On 4/21/20 3:30 PM, Kevin Brannen wrote:
I have an unusual need: I need Pg to slow down. I know, we all want our
DB to go faster, but in this case it's speed is working against me in 1 area.
We have systems that are geo-
Hi
I'm setting up a new environment with a primary/hot standby replication
pair.
For read-only clients, I have found the host=host1,host2 connection
string[1] which allows a connection when any one of the servers is up.
However I'm unsure how to achieve something similar for read/write
clients.
Hi,
What are the ETL tools there based on PostgreSQL.
I am looking for PG based MPP + ETL open source databases.
Thanks
Braj
On 4/21/20 7:43 PM, Virendra Kumar wrote:
Hi Adrian,
Here is test case, basically when autovacuum runs it did release the
space to disk since it had may be continuous blocks which can be
released to disk but the space used by index is still being held until I
ran the reindex on the table (I a
>From: Laurenz Albe
>
>>On Tue, 2020-04-21 at 20:30 +, Kevin Brannen wrote:
>> I have an unusual need: I need Pg to slow down. I know, we all want
>> our DB to go faster, but in this case it's speed is working against me in 1
>> area.
>>
>> [...] The part that hurts so bad is when we do main
PALAYRET Jacques writes:
> SELECT percentile_cont(1./3) WITHIN GROUP (ORDER BY c1) FROM x ;
> percentile_cont
> --
> 10.7
> (1 ligne)
> So, I though it should be :
> percentile_cont(1./3) = 10.5 (the arithmetic average between 10 et 11) and
> not 10.
With Libre Office Calc, same result than with PostgreSQL :
=CENTILE({1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27;28;29;30};
0.33)
gives
10.57 (and NOT 10.5)
I didn't think so.
De: "PALAYRET Jacques"
À: pgsql-general@lists.postgresql.org
Envoyé:
Of course, the same result with this table x(c1) for example :
SELECT c1, ntile(3) OVER(ORDER BY c1) FROM x ORDER BY c1 ;
c1 | ntile
+---
1 | 1
2 | 1
3 | 1
4 | 1
5 | 1
6 | 1
7 | 1
8 | 1
9 | 1
10 | 1
11 | 2
11 | 2
11 | 2
11 | 2
11 | 2
11 | 2
11 | 2
11 | 2
11 | 2
20 | 2
Hello,
>From a table x(c1) containing 30 lines with integer values (column c1) from 1
>to 30 :
SELECT percentile_cont(1./3) WITHIN GROUP (ORDER BY c1) FROM x ;
percentile_cont
--
10.7
(1 ligne)
SELECT percentile_cont(2./3) WITHIN GROUP (ORDER BY c1) FROM x ;
p
Hi all,
My understanding of a GIN index is that it maps each unique key to the set
of items containing that key. That suggests to me that enumerating the
distinct keys efficiently using the index should be possible in some cases.
I understand that given the nature of the GIN framework, the origina
On Tue, 2020-04-21 at 20:30 +, Kevin Brannen wrote:
> I have an unusual need: I need Pg to slow down. I know, we all want our DB
> to go faster,
> but in this case it's speed is working against me in 1 area.
>
> We have systems that are geo-redundant for HA, with the redundancy being
> hand
14 matches
Mail list logo
