> "Rich" == Rich Shepard writes:
Rich> I doubt that my use will notice meaningful differences. Since
Rich> there are only two or three databases in UTF8 and its collation
Rich> perhaps I'll convert those to LATIN1 and C.
Note that it's perfectly fine to use UTF8 encoding and C collation (
I've got a server at example.com that currently publishes logical
replication to a server in AWS RDS. I plan to move the server at example.com
so that it has a new IP address (but same domain name).
I'm curious if anybody knows how the logical replication subscriber in AWS
would handle that.
Ther
Thanks Peter for your answer.
I was hoping to keep the freedom of performing any change to my schema.
Since the entire upgrade might take more than a week, there will be a time in
which I have two publisher nodes with different schema versions (which might
include a column rename).
I was hoping
On Wed, 11 Dec 2019, Ron wrote:
The SUM() function?
Ron,
Interesting. I'll look at this, too.
Regards,
Rich
On Wed, 11 Dec 2019, Michael Lewis wrote:
Put what you have in a subquery and group/aggregate again.
select sample_count, count( site_nbr ) FROM (
select site_nbr, count(distinct sampdate) AS sample_count from wrb_hg_cong
group by site_nbr order by site_nbr
) sub
group by sample_count;
Michae
On Wed, Dec 11, 2019 at 1:54 PM Rich Shepard
wrote:
> A sampling location table has 28 distinct sites, each site being sampled
> from 1 to 67 times. I'm trying to obtain the number of sites having 1
> sample, 2 samples, ... 67 samples and am not seeing the solution despite
> several alternative q
A sampling location table has 28 distinct sites, each site being sampled
from 1 to 67 times. I'm trying to obtain the number of sites having 1
sample, 2 samples, ... 67 samples and am not seeing the solution despite
several alternative queries.
The query,
select site_nbr, count(distinct sampdate
On Wed, 11 Dec 2019, Tom Lane wrote:
String comparisons in non-C collations tend to be a lot slower than they
are in C collation. Whether this makes a noticeable difference to you
depends on your workload, but certainly we've seen performance gripes that
trace to that.
Tom,
How interesting.
Rich Shepard writes:
> My older databases have LATIN1 encoding and C collation; the newer ones have
> UTF8 encoding and en_US.UTF-8 collation. A web search taught me that I can
> change each old database by dumping it and restoring it with the desired
> encoding and collation types. My question is
Erwin Brandstetter writes:
> Guess Tom's warning in
> https://www.postgresql.org/message-id/9434.1568839...@sss.pgh.pa.us about
> portability only refers to hashtextextended() and friends not being there
> in Postgres 10 or older.
Well, the other portability issue that is worth considering is tha
My older databases have LATIN1 encoding and C collation; the newer ones have
UTF8 encoding and en_US.UTF-8 collation. A web search taught me that I can
change each old database by dumping it and restoring it with the desired
encoding and collation types. My question is whether the older types make
On Tue, Dec 10, 2019 at 11:34 PM Miles Elam
wrote:
> In terms of "wasted computation", MD5, SHA1, and the others always compute
> the full length before they are passed to a UUID, int, or whatever. It's a
> sunk cost. It's also a minor cost considering many hash algorithms are
> performed in CPU
Thanks for the suggestion. Seems like a good assumption and I have been
using hashtext() in the past. But I am uncertain whether it is the best
option.
Guess Tom's warning in
https://www.postgresql.org/message-id/9434.1568839...@sss.pgh.pa.us about
portability only refers to hashtextextended() and
On 12/11/19 9:06 AM, Tom Lane wrote:
Adrian Klaver writes:
On 12/11/19 5:18 AM, Олег Самойлов wrote:
This utility, like most other PostgreSQL utilities, also uses the environment
variables supported by libpq (see Section 33.14).
https://www.postgresql.org/docs/12/libpq-envars.html
PGUSER behav
Adrian Klaver writes:
> On 12/11/19 5:18 AM, Олег Самойлов wrote:
> This utility, like most other PostgreSQL utilities, also uses the environment
> variables supported by libpq (see Section 33.14).
> https://www.postgresql.org/docs/12/libpq-envars.html
> PGUSER behaves the same as the user connec
On 12/11/19 5:18 AM, Олег Самойлов wrote:
This utility, like most other PostgreSQL utilities, also uses the environment
variables supported by libpq (see Section 33.14).
"
https://www.postgresql.org/docs/12/libpq-envars.html
"
PGUSER behaves the same as the user connection parameter.
"
This
On 2019-12-10 08:55, Dan shmidt wrote:
What is the correct way to perform such an operation?
Is there a way to keep constraint #1 or the only option is to not allow
"breaking" schema changes between versions.
It all depends on the specific schema changes you want to make. You can
add columns
Greetings,
* Zwettler Markus (OIZ) (markus.zwett...@zuerich.ch) wrote:
> > * Zwettler Markus (OIZ) (markus.zwett...@zuerich.ch) wrote:
> > > We use "rsync" on XFS with "wsync" mount mode. I think this should do the
> > > job?
> >
> > No, that just makes sure that namespace operations are execute
>
> Greetings,
>
> * Zwettler Markus (OIZ) (markus.zwett...@zuerich.ch) wrote:
> > We use "rsync" on XFS with "wsync" mount mode. I think this should do the
> > job?
>
> No, that just makes sure that namespace operations are executed synchronously,
> that doesn't provide any guarantee that the
On 2019-12-10 17:53, Tom Lane wrote:
However, a multi-row insert like the following:
insert into test (id, data)
values
(default,1),
(default,2);
fails with:
ERROR: cannot insert into column "id"
Detail: Column "id" is an identity column defined as GENERATED AL
> 10 дек. 2019 г., в 18:36, Justin написал(а):
>
> Hi Oner
>
> It appears that you looking for a way to detect and kill of idle connections
> or process that are running for a long time Correct??
Nope, not idle. Only to stop an active connection if the client is already died.
> This utility, like most other PostgreSQL utilities, also uses the environment
> variables supported by libpq (see Section 33.14).
> "
>
> https://www.postgresql.org/docs/12/libpq-envars.html
> "
> PGUSER behaves the same as the user connection parameter.
> "
This is don't work with `initdb`
production experience.
Von: Dor Ben Dov
Gesendet: Montag, 9. Dezember 2019 13:24
An: Zwettler Markus (OIZ) ;
pgsql-general@lists.postgresql.org
Betreff: RE: PostgreSQL HA FO question
Hi Zwettler,
Based on what comparison, production experience ?
Regards,
Dor
From: Zwettler Markus (OIZ)
ma
23 matches
Mail list logo
