A little related bonus :
when doing the time-join,
the next step is to interpolate to have a more accurate estimation :
---
DROP FUNCTION IF EXISTS range_interpolate(nr anyrange,obs anyelement) ;
CREATE OR
> Anupama Ramaswamy wrote:
>>> I would like to setup a 2 servers with streaming replication, one master
>>> and another hot standby.
>>> I want to use the standby for read-only queries. So I want the replication
>>> lag to be as small as
>>> possible.
>>> So I choose streaming replication over WA
Hi,
I ran into some strange behavior.
Seems like a bug to me?
wbloos=# select round(0.5::numeric), round(0.5::double precision);
round | round
---+---
1 | 0
(1 row)
wbloos=# select version();
version
--
On Mon, 14 Apr 2014 15:22:13 -0700
Robert DiFalco wrote:
Hi Robert,
> But then I lose a bunch of data like the TIMESTAMPTZ of the call, answer,
> connection, etc. Btw, currently these tables never need to be UPDATEd. They
> are immutable in the current design.
Yes, but you wrote :
>Occasionall
I'm sorry Vincent I'm not exactly sure what you are proposing. Are you
proposing that I add another table in addition to what I already have that
all the other tables JOIN to and add a state field in that parent table?
How is that different than what I have except now I have a new table with
an upd
A couple of thoughts:
1) The "union" really only pertains to the entity table rows; once you
"union all" those (duplicates should not matter and probably will not even
be present so using "all" avoids an unnecessary sort) you can join that
sub-query to the document_usage table.
2) Since every ent
On Mon, 14 Apr 2014 09:27:29 -0700
Robert DiFalco wrote:
> I have several related tables that represent a call state.
>
> And so on for calls_connected, calls_completed, call_errors, etc.
>
> So for my question -- is the choice between these a personal preference
> sort of thing or is there a
*postgresql.conf:*
wal_level = hot_standby
hot_standby = on
archive_mode = on
archive_command = 'cp %p ../archive/%f'
## "archive" parallel to data directory
max_wal_senders = 10
## number of slaves
*recovery.conf(in slave)*
restore_command = 'cp ../archive/%f "%p"'
standby_mode = 'on'
primary_c
On Mon, Apr 14, 2014 at 12:27 PM, Robert DiFalco
wrote:
> I have several related tables that represent a call state. Let's think of
> these as phone calls to simplify things. Sometimes I need to determine the
> last time a user was called, the last time a user answered a call, or the
> last time a
On Tue, Apr 15, 2014 at 10:56 AM, Chris Curvey wrote:
> On Mon, Apr 14, 2014 at 12:27 PM, Robert DiFalco > wrote:
>
>> I have several related tables that represent a call state. Let's think of
>> these as phone calls to simplify things. Sometimes I need to determine the
>> last time a user was ca
On Tue, 15 Apr 2014 07:21:58 -0700
Robert DiFalco wrote:
> I'm sorry Vincent I'm not exactly sure what you are proposing. Are you
> proposing that I add another table in addition to what I already have that
> all the other tables JOIN to and add a state field in that parent table?
No : keep tabl
Actually that was exactly the initial table design. There were more fields
because for my use case there were a lot more states and certain states
have additional data (for example when a call goes from answered to
connected it also gets the user_id of the person being connected to). So
that one ta
On 04/15/2014 09:53 AM, Robert DiFalco wrote:
Actually that was exactly the initial table design. There were more
fields because for my use case there were a lot more states and
certain states have additional data (for example when a call goes from
answered to connected it also gets the user_id
Willy-Bas Loos-3 wrote
> Hi,
> I ran into some strange behavior.
> Seems like a bug to me?
>
> wbloos=# select round(0.5::numeric), round(0.5::double precision);
> round | round
> ---+---
> 1 | 0
> (1 row)
Not a bug; and likely to simple to have escaped notice this long so the
f
On 15/04/2014 17:20, David G Johnston wrote:
> Willy-Bas Loos-3 wrote
>> Hi, I ran into some strange behavior. Seems like a bug to me?
>>
>> wbloos=# select round(0.5::numeric), round(0.5::double precision);
>> round | round ---+--- 1 | 0 (1 row)
>
> Not a bug; and likely to simple t
Raymond O'Donnell wrote
> On 15/04/2014 17:20, David G Johnston wrote:
>> Willy-Bas Loos-3 wrote
>>> Hi, I ran into some strange behavior. Seems like a bug to me?
>>>
>>> wbloos=# select round(0.5::numeric), round(0.5::double precision);
>>> round | round ---+--- 1 | 0 (1 row)
>>
>>
On 15/04/2014 17:34, David G Johnston wrote:
> Raymond O'Donnell wrote
>> On 15/04/2014 17:20, David G Johnston wrote:
>>> Willy-Bas Loos-3 wrote
Hi, I ran into some strange behavior. Seems like a bug to me?
wbloos=# select round(0.5::numeric), round(0.5::double precision);
rou
On 4/14/2014 12:27 PM, Robert DiFalco wrote:
And so on for calls_connected, calls_completed, call_errors, etc.
Occasionally I will want to know things like "When was the last time a
user answered a call" or "How many times has a user been called".
...
Sometimes I might want to get this data fo
On 04/15/2014 10:21 AM, Raymond O'Donnell wrote:
On 15/04/2014 17:34, David G Johnston wrote:
Oh, so does the rounding code use OS facilities, then, rather than being
implemented in Postgres? - Didn't know that, though I was aware PG does
that in other areas (collation, for example).
See th
1. >500K rows per day into the calls table.
2. Very rarely. The only common query is gathering users that have not been
called "today" (along with some other qualifying criteria). More analytical
queries/reports are done for internal use and it is not essential that they
be lickity-split.
a. Usuall
On 16/04/14 13:10, Robert DiFalco wrote:
1. >500K rows per day into the calls table.
2. Very rarely. The only common query is gathering users that have not
been called "today" (along with some other qualifying criteria). More
analytical queries/reports are done for internal use and it is not
e
Some more information on this:
>
> > I say "hang", where really I've given up after ~12 hours execution. The
> > exact same query can then be terminated and run in <90 seconds, with none
> > of the underlying data changing.
>
> But does the plan change?
>
>
As it turns out it does. Some further ex
Are there any plans to add "in-place at-depth" update operator for JSONB
type, e.g.:
UPDATE test SET attrs->'anwser' = 42 where attrs->'answer' = 41
Hi
I am locking some rows using select for update(nowait=true) inside a
transaction.If server in which code exists crashes,locks will be on
rows.Those should be removed manually.I donot want that.I want to keep a
timeout for that transaction.Could you please helpme out with a solution
for this issu
On Tue, 15 Apr 2014 22:07:09 +
Samir Parikh wrote:
> Thanks Alberto. I could figure out that and install the software
> successfully.
> Is there any nice document you can suggest for configuring slony (set up
> replication, sets,nodes etc...).
Hi, Samir.
There are many. You should begin w
25 matches
Mail list logo
