Re: [GENERAL] Installing 9.6 RC on Ubuntu [Solved]

2016-09-13 Thread Adrian Klaver
On 09/13/2016 06:17 PM, Steve Crawford wrote: In case it is useful for reference, I beat my head on it a bit more and replaced "main" with "9.6": deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg 9.6

Re: [GENERAL] select date between - PostgreSQL 9.5

2016-09-13 Thread Patrick B
2016-09-14 13:17 GMT+12:00 David Rowley : > On 14 September 2016 at 12:20, Patrick B wrote: > > I want to select all rows that have been modified from now to 4 months > ago. > > > > I've used these queries: > > > >> select > >>

Re: [GENERAL] select date between - PostgreSQL 9.5

2016-09-13 Thread David Rowley
On 14 September 2016 at 12:20, Patrick B wrote: > I want to select all rows that have been modified from now to 4 months ago. > > I've used these queries: > >> select >> modified_date, >> from >> clients >> WHERE >> modified_date BETWEEN '2016-06-13' AND

Re: [GENERAL] Installing 9.6 RC on Ubuntu [Solved]

2016-09-13 Thread Steve Crawford
> >> In case it is useful for reference, I beat my head on it a bit more and >> replaced "main" with "9.6": >> deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg 9.6 >> > > Yes, that is an FAQ item: > > https://wiki.postgresql.org/wiki/Apt/FAQ > > Yes, but to quote Douglass Adams, "It was

Re: [GENERAL] select date between - PostgreSQL 9.5

2016-09-13 Thread Vitaly Burovoy
On 9/13/16, Patrick B wrote: > Hi guys, > > I got the following column: > > modified_date TIMESTAMP(6) WITHOUT TIME ZONE DEFAULT >> "statement_timestamp"(), > > > I want to select all rows that have been modified from now to 4 months ago. > > I've used these queries: > >

Re: [GENERAL] select date between - PostgreSQL 9.5

2016-09-13 Thread Adrian Klaver
On 09/13/2016 05:20 PM, Patrick B wrote: Hi guys, I got the following column: modified_date TIMESTAMP(6) WITHOUT TIME ZONE DEFAULT "statement_timestamp"(), I want to select all rows that have been modified from now to 4 months ago. I've used these queries: select

[GENERAL] select date between - PostgreSQL 9.5

2016-09-13 Thread Patrick B
Hi guys, I got the following column: modified_date TIMESTAMP(6) WITHOUT TIME ZONE DEFAULT > "statement_timestamp"(), I want to select all rows that have been modified from now to 4 months ago. I've used these queries: select > modified_date, > from > clients > WHERE >

Re: [GENERAL] Installing 9.6 RC on Ubuntu [Solved]

2016-09-13 Thread Adrian Klaver
On 09/13/2016 11:23 AM, Steve Crawford wrote: On Tue, Sep 13, 2016 at 11:03 AM, Steve Crawford > wrote: I'm trying to install 9.6 RC1 on Ubuntu 16.04 Xenial on my laptop and it seems broken. Installation of 9.6

[GENERAL] Event trigger and CREATE/ALTER ROLE/USER

2016-09-13 Thread Tatsuo Ishii
Simple question: Is there any reason for event trigger to not support CREATE/ALTER ROLE/USER? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org)

Re: [GENERAL] Predicting query runtime

2016-09-13 Thread Vinicius Segalin
2016-09-13 17:12 GMT-03:00 Oleg Bartunov : > > > FYI, please check https://pgconf.ru/2016/89977 > > Interesting! Was this presentation filmed? Or would you have a post or something else with more details?

Re: [GENERAL] Maximum number of exclusive locks

2016-09-13 Thread Tom Lane
Jeff Janes writes: > On Tue, Sep 13, 2016 at 6:21 AM, Tom Lane wrote: >> Having said that, the amount of slop involved is only enough for a >> few hundred lock entries. Not sure how you're managing to get to >> nearly 2 extra entries. > The code

Re: [GENERAL] Maximum number of exclusive locks

2016-09-13 Thread Jeff Janes
On Tue, Sep 13, 2016 at 6:21 AM, Tom Lane wrote: > "Daniel Verite" writes: > > Nothing to complain about, but why would the above formula > > underestimate the number of object locks actually available > > to a transaction? Isn't it supposed to be a

Re: [GENERAL] Predicting query runtime

2016-09-13 Thread Oleg Bartunov
On Tue, Sep 13, 2016 at 2:54 PM, Istvan Soos wrote: > On Tue, Sep 13, 2016 at 2:06 AM, Vinicius Segalin > wrote: >> 2016-09-12 18:22 GMT-03:00 Istvan Soos : >>> At Heap we have non-trivial complexity in our analytical queries,

Re: [GENERAL] Predicting query runtime

2016-09-13 Thread Istvan Soos
On Tue, Sep 13, 2016 at 2:06 AM, Vinicius Segalin wrote: > 2016-09-12 18:22 GMT-03:00 Istvan Soos : >> At Heap we have non-trivial complexity in our analytical queries, and >> some of them can take a long time to complete. We did analyze features >>

Re: [GENERAL] Installing 9.6 RC on Ubuntu [Solved]

2016-09-13 Thread Steve Crawford
On Tue, Sep 13, 2016 at 11:03 AM, Steve Crawford < scrawf...@pinpointresearch.com> wrote: > I'm trying to install 9.6 RC1 on Ubuntu 16.04 Xenial on my laptop and it > seems broken. > > Installation of 9.6 RC1 on Centos was straightforward by comparison - just > add the 9.6 yum package and

[GENERAL] Installing 9.6 RC on Ubuntu

2016-09-13 Thread Steve Crawford
I'm trying to install 9.6 RC1 on Ubuntu 16.04 Xenial on my laptop and it seems broken. Installation of 9.6 RC1 on Centos was straightforward by comparison - just add the 9.6 yum package and install. Unfortunately Ubuntu seems second-class by comparison. I already have /etc/apt.repos.d/pgdg.list

Re: [GENERAL] Predicting query runtime

2016-09-13 Thread Hu, Patricia
I’ve been looking for this on postgres too. Does Postgres have something similar to Oracle’s v$session_longops? It gives info on total unit of work, units done so far, last update time, and time remaining etc, and I found it valuable in providing an estimate to how long a certain query would

Re: [GENERAL] Maximum number of exclusive locks

2016-09-13 Thread Tom Lane
"Daniel Verite" writes: > Nothing to complain about, but why would the above formula > underestimate the number of object locks actually available > to a transaction? Isn't it supposed to be a hard cap for such > locks? No, it's a minimum not a maximum. There's

[GENERAL] Maximum number of exclusive locks

2016-09-13 Thread Daniel Verite
Hi, When deleting large objects, an exclusive lock is grabbed on each object individually. As a result, a transaction that does it en masse can encounter this error: ERROR: out of shared memory HINT: You might need to increase max_locks_per_transaction. I would expect the maximum number