On Thu, Jan 17, 2019 at 4:13 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Thu, Jan 17, 2019 at 9:19 AM Ben Snaidero
> wrote:
> > Any ideas as to why this is happening?
>
> Not really, I would expect roughly double execution time, not an
> exponential increase. Still not experie
On Thu, 17 Jan 2019, David G. Johnston wrote:
I would advise changing Contacts to "Activities" as the former can readily
be interpreted (and is in the wild) as both "an instance of contacting a
person" and "the person at the organization who is being contacted" (i.e.,
your People class).
David
On Thu, Jan 17, 2019 at 3:44 PM Rich Shepard wrote:
> FROM People AS p
> JOIN Organizations AS o ON p.org_id = o.org_id
> JOIN Contacts AS c ON c.person_id = p.person_id
I would advise changing Contacts to "Activities" as the former can
readily be interpreted (and is in the wild) as b
On Thu, 17 Jan 2019, Adrian Klaver wrote:
I would think the active would be on People or Organizations. Then you can
eliminate then from the query results before you ever got to the contact
history.
Adrian,
Excellent point. I don't know why I put active in the contacts table as it
does make m
On 1/17/19 2:44 PM, Rich Shepard wrote:
On Thu, 17 Jan 2019, Adrian Klaver wrote:
Got to thinking more and realized the answer depends on what you want the
query to produce. Can you let us know what is you are trying to pull out
with the query?
Adrian, et al.,
Took your advice and re-thought
On Thu, 17 Jan 2019, Adrian Klaver wrote:
Got to thinking more and realized the answer depends on what you want the
query to produce. Can you let us know what is you are trying to pull out
with the query?
Adrian, et al.,
Took your advice and re-thought what I need the query to return. This
al
On Thu, Jan 17, 2019 at 9:19 AM Ben Snaidero wrote:
> Any ideas as to why this is happening?
Not really, I would expect roughly double execution time, not an
exponential increase. Still not experienced enough to diagnose with
what has been provided but I will suggest you provide the version that
Hi Karl,
I'm going down this road myself. In addition to the files Tom Lane pointed
out there is also some helpful documentation here:
https://www.postgresql.org/docs/current/storage-toast.html#STORAGE-TOAST-INMEMORY
On Wed, Jan 16, 2019 at 2:09 PM Sam Patterson wrote:
> Hi all,
>
> I've rece
Ben Snaidero wrote:
> The following query runs as expected.
>
> explain analyze SELECT MainTable.gid AS MainTable_gid,MainTable.datetime AS
> MainTable_datetime,MainTable.objectid AS MainTable_objectid,MainTable.type AS
> MainTable_type FROM MainTable
>WHERE objectid = ANY(ARRAY(SELECT NE.
Hi all,
I am working on a migration from Oracle to PostgreSQL using the AWS SCT.
I had converted 823 table out of 866 tables to postgres. However for few
tables I am facing challenges in convertion due to
"aws_oracle_ext.systimestamp" fuctions.
below is the Error for your reference.
ERROR: func
On Thu, 17 Jan 2019, Adrian Klaver wrote:
It would produce results, so yes it would work. The question are they the
results you want?
Adrian,
To which the answer is no as I just discovered.
The above would return anything with a next_contact less then today. That
could extend backwards to
On 1/17/19 10:01 AM, Rich Shepard wrote:
On Thu, 17 Jan 2019, Adrian Klaver wrote:
Seems to me a boolean field of name active to denote contacts you need to
keep up with is in order. Then make the next_contact field NOT NULL and
replace the current NULL values with 'infinity':
WHERE COALESCE
On Thu, 17 Jan 2019, David G. Johnston wrote:
Off the top of my head (and this is a model I am quite familiar with
even if I'm doing this email at speed):
I'd suggest an actual activity table:
David,
Adrian's suggestion of a Contacts table column called 'active' having a
boolean data type
Thanks, I'll check it out.
On Thu, Jan 17, 2019 at 9:06 AM Jehan-Guillaume (ioguix) de Rorthais <
iog...@free.fr> wrote:
> On Thu, 17 Jan 2019 08:32:48 -0500
> AI Rumman wrote:
>
> > Hi,
> >
> > I am planning to use Postgresql with TimescaleDb extension. I have to
> > design a system similar to
On Thu, 17 Jan 2019, Adrian Klaver wrote:
Seems to me a boolean field of name active to denote contacts you need to
keep up with is in order. Then make the next_contact field NOT NULL and
replace the current NULL values with 'infinity':
WHERE COALESCE(next_contact, 'infinity') BETWEEN '01/01/
On Thu, 17 Jan 2019, Adrian Klaver wrote:
To be clear the next-activity date = next_contact in the database, correct?
Adrian,
Yes. I've renamed the Activities table to Contacts and the Contacts table
to People.
NULL basically means unknown, so having it stand for something is a bit of
a s
On Thu, Jan 17, 2019 at 10:07 AM Rich Shepard wrote:
>The direct answer is that a completed activity has a row with either a
> future next-activity date or a null (which is the case when the status of
> that organization or contact is 'no further contact'.)
Off the top of my head (and this is
On 1/17/19 9:07 AM, Rich Shepard wrote:
On Thu, 17 Jan 2019, David G. Johnston wrote:
Yes...though now it just sounds like a flawed data model.
David,
This is what I thought.
How stuck are you in that regard? Those "future" contacts should have
their
own records and not be derived via
On Thu, 17 Jan 2019, David G. Johnston wrote:
Yes...though now it just sounds like a flawed data model.
David,
This is what I thought.
How stuck are you in that regard? Those "future" contacts should have their
own records and not be derived via an optional field on an existing
record.
On Thu, Jan 17, 2019 at 9:47 AM Rich Shepard wrote:
> What I want is a list of contacts to make today. This includes ones that
> should have been made earlier but weren't and excludes earlier contacts that
> have no scheduled next contact (therefore, the nulls.).
>
> Does this clarify what I'm ask
On Thu, 17 Jan 2019, Adrian Klaver wrote:
Got to thinking more and realized the answer depends on what you want the
query to produce. Can you let us know what is you are trying to pull out
with the query?
Adrian,
Certainly. Over breakfast I realized the same thing: the existing SELECT
query i
On Thu, 17 Jan 2019, David G. Johnston wrote:
Why is next_contact allowed to be null?
David,
There are a number of reasons. The prospect might have retired, told me to
pound sand, or has put off a decision.
Your concept of "most current row" is strictly based upon next_contact so
if next_co
On 1/17/19 8:14 AM, Rich Shepard wrote:
On Tue, 15 Jan 2019, Thomas Kellerer wrote:
select distinct on (C.contact_id) C.contact_id, C.lname, C.fname,
C.direct_phone, O.org_name, A.next_contact
from Contacts as C
join Organizations as O on C.org_id = O.org_id
join Activities as
On Thu, Jan 17, 2019 at 9:14 AM Rich Shepard wrote:
> ORDER BY c.contact_id, a.next_contact DESC;
> The WHERE clause needs to exclude a contact_id where the most current row in
> Activities has NULL for the next_contact column.
Why is next_contact allowed to be null?
Your concept of "most curre
On 1/17/19 8:14 AM, Rich Shepard wrote:
On Tue, 15 Jan 2019, Thomas Kellerer wrote:
select distinct on (C.contact_id) C.contact_id, C.lname, C.fname,
C.direct_phone, O.org_name, A.next_contact
from Contacts as C
join Organizations as O on C.org_id = O.org_id
join Activities as
On Thu, Jan 17, 2019 at 9:06 AM Fabio Pardi wrote:
> Are you sure? The behaviour I experienced is different from what you
> described.
85%...
>
> On 17/01/2019 16:32, David G. Johnston wrote:
> > On Thu, Jan 17, 2019 at 8:18 AM Nicola Contu wrote:
> >>
> >> Hello,
> >> I am a bit confused about
The following query runs as expected.
explain analyze SELECT MainTable.gid AS MainTable_gid,MainTable.datetime AS
MainTable_datetime,MainTable.objectid AS MainTable_objectid,MainTable.type
AS MainTable_type FROM MainTable
WHERE objectid = ANY(ARRAY(SELECT NE.objectid AS entityId FROM (
nodeobje
> If I set 3, and I tried to connect from 4 shells, I am still able to
connect.
That would be the point - pgbouncer is sharing the 3 connections it
keeps with PostgreSQL between the 4 client connections made to it.
Mmh, my pool_mode is per session. The 4 sessions were active, not doing any
query,
On Tue, 15 Jan 2019, Thomas Kellerer wrote:
select distinct on (C.contact_id) C.contact_id, C.lname, C.fname,
C.direct_phone, O.org_name, A.next_contact
from Contacts as C
join Organizations as O on C.org_id = O.org_id
join Activities as A on C.contact_id = A.contact_id
where
David,
Are you sure? The behaviour I experienced is different from what you described.
On 17/01/2019 16:32, David G. Johnston wrote:
> On Thu, Jan 17, 2019 at 8:18 AM Nicola Contu wrote:
>>
>> Hello,
>> I am a bit confused about the settings in pgbouncer
>>
>> What's exactly the pool_size?
>
>
On Thu, Jan 17, 2019 at 8:39 AM Rich Shepard wrote:
>
> On Thu, 17 Jan 2019, Rich Shepard wrote:
>
> > I want only to confirm that I can use /* ... */ for multiline comments in my
> > DDL and DML scripts.
>
> Oops! Section 4.1.5 tells me that I can.
>
You could also just try it...
select 1 /* co
On Thu, 17 Jan 2019, Rich Shepard wrote:
I want only to confirm that I can use /* ... */ for multiline comments in my
DDL and DML scripts.
Oops! Section 4.1.5 tells me that I can.
Apologies to all,
Rich
I know that "--" has been the single-line comment identifier since SQL was
implemented by IBM on mainframes using Hollerith cards. Today, some RDBMSs
also allow the C comment indentifier pair, /* ... */.
The postgres10 manual when searched for 'comments' presents the double
hyphens and, in Sectio
On Thu, Jan 17, 2019 at 8:18 AM Nicola Contu wrote:
>
> Hello,
> I am a bit confused about the settings in pgbouncer
>
> What's exactly the pool_size?
Roughly, the number of open connections pgbouncer will keep to PostgreSQL.
> If I set 3, and I tried to connect from 4 shells, I am still able to
Hello,
I am a bit confused about the settings in pgbouncer
What's exactly the pool_size?
If I set 3, and I tried to connect from 4 shells, I am still able to
connect.
Same thing for max_db_connections. I set this to 1 and I am able to connect
from 2 shells.
This is kind of confusing and I'm not r
On 17/1/19 4:12 μ.μ., Jehan-Guillaume (ioguix) de Rorthais wrote:
On Thu, 17 Jan 2019 13:09:18 +0200
Achilleas Mantzios wrote:
Hello,
One strong point of barman IMHO is transparently converting an incremental
backup to a full backup for retention purposes, so retention specification is
far mo
Hi
For PostgreSQL Automatic Failover , we are using repmgr too.
Best Regards
Didier ROS
Expertise SGBD
DS IT/IT DMA/Solutions Groupe EDF/Expertise Applicative - SGBD
-Message d'origine-
De : f.pa...@portavita.eu [mailto:f.pa...@portavita.eu]
Envoyé : jeudi 17 janvier 2019 15:29
À : pgsq
Hi,
In my opinion repmgr it's worth a look.
https://repmgr.org/
regards,
fabio pardi
On 17/01/2019 14:32, AI Rumman wrote:
> Hi,
>
> I am planning to use Postgresql with TimescaleDb extension. I have to design
> a system similar to AWS RDS which supports automated failover, transparent
>
On Thu, 17 Jan 2019 13:09:18 +0200
Achilleas Mantzios wrote:
> Hello,
>
> One strong point of barman IMHO is transparently converting an incremental
> backup to a full backup for retention purposes, so retention specification is
> far more liberal than with pgbackrest, and configuring for increm
On Thu, 17 Jan 2019 08:32:48 -0500
AI Rumman wrote:
> Hi,
>
> I am planning to use Postgresql with TimescaleDb extension. I have to
> design a system similar to AWS RDS which supports automated failover,
> transparent minor version upgrades etc.
> In early days, I worked with PgPool II to enable
There is postgres multimaster replication. Please explore bdr multi master
node.
On Thu, Jan 17, 2019 at 7:03 PM AI Rumman wrote:
> Hi,
>
> I am planning to use Postgresql with TimescaleDb extension. I have to
> design a system similar to AWS RDS which supports automated failover,
> transparent
Hi,
I am planning to use Postgresql with TimescaleDb extension. I have to
design a system similar to AWS RDS which supports automated failover,
transparent minor version upgrades etc.
In early days, I worked with PgPool II to enable heartbeat between the
Postgres servers. Is there any new tool to
Hello,
One strong point of barman IMHO is transparently converting an incremental backup to a full backup for retention purposes, so retention specification is far more liberal than with pgbackrest, and
configuring for incremental backup does not pose any limitations to the schedule of backups.
Le jeu. 17 janv. 2019 à 08:27, Andrew Gierth
a écrit :
> > "Guillaume" == Guillaume Lelarge writes:
>
> >> I will see about fixing this, somehow.
>
> Guillaume> Thanks a lot.
>
> I've committed a fix (to all supported branches, since this bug actually
> precedes the addition of GROUPING SE
44 matches
Mail list logo
