Thanks a lot Jeremy, we ended up integrating the code you provided
into our software (just before you patent it) :)
Best regards,
Kkh
On Tue, Oct 3, 2017 at 7:58 PM, Schneider wrote:
> On Mon, Oct 2, 2017 at 10:27 AM, Khalil Khamlichi
> wrote:
>> we have records like this
>>
>> ccdb1=# select
Thanks, I'll check it out.
Sent via mobile, please forgive typos and brevity
On Oct 14, 2017 3:23 PM, "Joshua D. Drake" wrote:
> On 10/01/2017 01:17 AM, Khalil Khamlichi wrote:
>
>> Hi everyone,
>>
>
> Take a look at TimescaleDB they have an extension to Postgres that makes
> this awesome (and
On 10/01/2017 01:17 AM, Khalil Khamlichi wrote:
Hi everyone,
Take a look at TimescaleDB they have an extension to Postgres that makes
this awesome (and yes its free and open source).
jD
I have a data stream of a call center application coming in to postgres
in this format :
user_name,
On Mon, Oct 2, 2017 at 10:27 AM, Khalil Khamlichi
wrote:
> we have records like this
>
> ccdb1=# select user_name, agent_status, event_time from cc_events ;
>
> user_name | agent_status | event_time
> ---+--+-
> user1 | ready| 2017-01-01 10
You have these choices:
- turn events into INSERTs and UPDATES on a table that represents a
single call
You might have an events VIEW with INSTED OF insert/update triggers
so you can insert events as the interface for updating calls.
- store the events and have a VIEW on the events t
Hi Melvin,
Thanks a lot for your help,
let me explain to you my problem.
we have records like this
ccdb1=# select user_name, agent_status, event_time from cc_events ;
user_name | agent_status | event_time
---+--+-
user1 | ready| 2017-01
interesting proposition, I am reading the docs.
On Mon, Oct 2, 2017 at 6:08 PM, Scott Marlowe
wrote:
> On Sun, Oct 1, 2017 at 2:17 AM, Khalil Khamlichi
> wrote:
> > Hi everyone,
> >
> > I have a data stream of a call center application coming in to postgres
> in
> > this format :
> >
> > user_
On Sun, Oct 1, 2017 at 2:17 AM, Khalil Khamlichi
wrote:
> Hi everyone,
>
> I have a data stream of a call center application coming in to postgres in
> this format :
>
> user_name, user_status, event_time
>
> 'user1', 'ready', '2017-01-01 10:00:00'
> 'user1', 'talking', '2017-01-01 10:02:00'
> 'u
On Sun, Oct 1, 2017 at 6:20 PM, Clifford Snow
wrote:
> I have a stream that updates every minute with a trigger that updates
> another table with information from the stream. That way I'm constantly
> updated with no need to run a script to update before I want a report.
>
> Clifford
>
> On Sun,
I have a stream that updates every minute with a trigger that updates
another table with information from the stream. That way I'm constantly
updated with no need to run a script to update before I want a report.
Clifford
On Sun, Oct 1, 2017 at 10:08 AM, Melvin Davidson
wrote:
>
>
> On Sun, Oct
On Sun, Oct 1, 2017 at 4:17 AM, Khalil Khamlichi wrote:
> Hi everyone,
>
> I have a data stream of a call center application coming in to postgres
> in this format :
>
> user_name, user_status, event_time
>
> 'user1', 'ready', '2017-01-01 10:00:00'
> 'user1', 'talking', '2017-01-01 10:02:00'
> '
Hi everyone,
I have a data stream of a call center application coming in to postgres in
this format :
user_name, user_status, event_time
'user1', 'ready', '2017-01-01 10:00:00'
'user1', 'talking', '2017-01-01 10:02:00'
'user1', 'after_call', '2017-01-01 10:07:00'
'user1', 'ready', '2017-01-01 1
On Thu, Sep 29, 2016 at 3:20 PM, Thomas Munro wrote:
> On Fri, Sep 30, 2016 at 8:17 AM, Kevin Grittner wrote:
> > On Thu, Sep 29, 2016 at 2:06 PM, Melvin Davidson
> wrote:
> >
> >> I am using PostgreSQL 9.4.0 (Yes, I know 9.4.9 is most recent but
> >> it's out of my control)
> >
> > As long as
On Fri, Sep 30, 2016 at 8:17 AM, Kevin Grittner wrote:
> On Thu, Sep 29, 2016 at 2:06 PM, Melvin Davidson wrote:
>
>> I am using PostgreSQL 9.4.0 (Yes, I know 9.4.9 is most recent but
>> it's out of my control)
>
> As long as the decision-maker is aware that 9.4.0 has known bugs
> (fixed in later
Hi Melvin:
On 09/29/2016 12:06 PM, Melvin Davidson wrote:
I list the creation time for a WAL file and it shows:
/home/mdavidson/dba$ ls -l --time=ctime
/d-log/pg_xlog/0001000D00C9
-rw--- 1 postgres postgres 16777216 Sep 29 07:14
/d-log/pg_xlog/0001000D00C9
ctime s
On Thu, Sep 29, 2016 at 2:06 PM, Melvin Davidson wrote:
> I am using PostgreSQL 9.4.0 (Yes, I know 9.4.9 is most recent but
> it's out of my control)
As long as the decision-maker is aware that 9.4.0 has known bugs
(fixed in later minor releases) that can render the database
unusable without war
*So here is a strange question. I am using PostgreSQL 9.4.0 (Yes, I know
9.4.9 is most recent but it's out of my control) O/S is AWS Debian 3.16.7-2
(2014-11-06) x86_64 GNU/Linux. I list the creation time for a WAL file and
it shows: /home/mdavidson/dba$ ls -l --time=ctime
/d-log/pg_xlog/000100
Good deduction Steve.
Looks like we are going to use the timestamp idea. This way, the ticket will
be open for sale again the second it's hold_until time lapses. The cronjob was
a close second, but there could be a lag-time between runs.
Thanks everyone for all the help.
--
Robert Sosinski
On 09/18/2012 08:59 AM, Robert Sosinski wrote:
We have a table, which has items that can be put on hold of 5 minutes
(this is for an online store) once they are placed into a cart. What
we need is for this hold to automatically expire after 5 minutes.
Right now, we put a time stamp into the r
On 09/18/2012 10:03 AM, Szymon Guz wrote:
On 18 September 2012 17:59, Robert Sosinski
mailto:rsosin...@ticketevolution.com>>
wrote:
We have a table, which has items that can be put on hold of 5
minutes (this is for an online store) once they are placed into a
cart. What we need is f
On 18 September 2012 17:59, Robert Sosinski
wrote:
> We have a table, which has items that can be put on hold of 5 minutes
> (this is for an online store) once they are placed into a cart. What we
> need is for this hold to automatically expire after 5 minutes. Right now,
> we put a time stamp
We have a table, which has items that can be put on hold of 5 minutes (this is
for an online store) once they are placed into a cart. What we need is for
this hold to automatically expire after 5 minutes. Right now, we put a time
stamp into the row (called hold_until) at 5 minutes into the fut
On Monday, January 16, 2012 5:50:42 am Cefull Lo wrote:
> Hi,
> I figure it out.
> If only the offset from UTC is given, you may try
>
> select current_timestamp at time zone (select name from
> pg_catalog.pg_timezone_names where utc_offset= interval '+8 hours' limit 1)
>
> Would give the exact t
On Monday, January 16, 2012 5:50:42 am Cefull Lo wrote:
> Hi,
> I figure it out.
> If only the offset from UTC is given, you may try
>
> select current_timestamp at time zone (select name from
> pg_catalog.pg_timezone_names where utc_offset= interval '+8 hours' limit 1)
>
> Would give the exact t
Hi,
I figure it out.
If only the offset from UTC is given, you may try
select current_timestamp at time zone (select name from
pg_catalog.pg_timezone_names where utc_offset= interval '+8 hours' limit 1)
Would give the exact timestamp at those time zone.
On Fri, Jan 13, 2012 at 11:59 PM, Cefull
On 01/13/2012 08:18 AM, Tom Lane wrote:
Cefull Lo writes:
I'm located in Hong Kong, UTC+8 time zone. When I
select current_timestamp;
2012-01-13 23:56:16.825558+08
However, when I
select current_timestamp at time zone 'UTC+8';
I expect the result is the same as the above one.
Sorry, but it i
Cefull Lo writes:
> I'm located in Hong Kong, UTC+8 time zone. When I
> select current_timestamp;
> 2012-01-13 23:56:16.825558+08
> However, when I
> select current_timestamp at time zone 'UTC+8';
> I expect the result is the same as the above one.
Sorry, but it isn't. A time zone name spelled
Hi everybody,
I'm located in Hong Kong, UTC+8 time zone. When I
select current_timestamp;
gives
now
---
2012-01-13 23:56:16.825558+08
However, when I
select current_timestamp at time zone 'UTC+8';
I expect the result is the same as the above one. But
On 10/01/2012 3:10 AM, Jason Buberel wrote:
"Select median price for every zip code as of 2012-01-06" (customer
exports)
"Select median price for 94086 from 2005-01-01 through 2012-01-06"
(charting apps)
So by partitioning in one dimension we impact queries in the other.
Well, I know of *the
Hi,
On 10 January 2012 06:10, Jason Buberel wrote:
> "Select median price for every zip code as of 2012-01-06" (customer exports)
> "Select median price for 94086 from 2005-01-01 through 2012-01-06" (charting
> apps)
>
> So by partitioning in one dimension we impact queries in the other.
I do no
Craig,
Good suggestion - I have experimented with table partitioning in the past,
but the impact on performance was considerable.
In our case, we have one large table with real estate statistics arranged
in time (weekly for the last five years) and geography (every zip in the
US). You could imagi
Hi,
On 8 January 2012 01:52, Jason Buberel wrote:
> psql> create tablespace 'newstorage' location '/some/new/path';
> psql> alter table city_summary set tablespace = 'newstorage';
Be aware that you are not going to move indexes (see ALTER INDEX name
SET TABLESPACE tablespace_name). Maybe you don
On 7/01/2012 10:52 PM, Jason Buberel wrote:
I'm considering the migration of an existing large (2.3TB) table to a
new tablespace. The table size, according to the '\dt+' command:
public | city_summary | table | altosresearch | 2345 GB|
Are there any considerations - besides the usual disk
I'm considering the migration of an existing large (2.3TB) table to a new
tablespace. The table size, according to the '\dt+' command:
public | city_summary | table | altosresearch | 2345 GB|
Are there any considerations - besides the usual disk and network IO
constraints - that I need to ta
Hello,
I have a view which is a result of the cross product of three tables, I want to
test how much time is required to populate this view. Also, I want to test the
scalability of this view in the future. Since, I have already live data I am
wondering if I can do that without creating an autom
On May 8, 2011, at 11:40 AM, Adrian Klaver wrote:
> No, PST has an offset of -8.
Head > desk. Thank you.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
On Sunday, May 08, 2011 10:23:44 am Christophe Pettus wrote:
> Either I am exceptionally confused, or the documentation in 8.5.3 appears
> to be wrong. Could someone clarify what I'm missing?
>
> The documentation states: "In short, this is the difference between
> abbreviations and full names: a
Either I am exceptionally confused, or the documentation in 8.5.3 appears to be
wrong. Could someone clarify what I'm missing?
The documentation states: "In short, this is the difference between
abbreviations and full names: abbreviations always represent a fixed offset
from UTC, whereas most
On 15 Jan 2011, at 1:41, bubba postgres wrote:
> I've been googling, but haven't found a good answer to what I should do if I
> want to store time series in Postgres.
> My current solution is store serialized (compressed) blobs of data.
> (So for example store 1 day worth of 1 minute samples (~14
On 2011-01-15, bubba postgres wrote:
> --000e0cd332267ac2e60499d7ceb2
> Content-Type: text/plain; charset=ISO-8859-1
>
> I've been googling, but haven't found a good answer to what I should do if I
> want to store time series in Postgres.
> It would be nice if I could use 1 sample per column,(bec
I think you want to look at kdb, onetick, and LIM (those are
commercial). or potentially mongoDB where you could probably store a
compressed ts directly in the db if you want.
If you're not going to store each observation as a row, then why use a
db at all. why not stick to flat files?
-Whit
O
I've been googling, but haven't found a good answer to what I should do if I
want to store time series in Postgres.
My current solution is store serialized (compressed) blobs of data.
(So for example store 1 day worth of 1 minute samples (~1440 samples) stored
as one row in a bytea. (Plus meta data
silly writes:
>> From
>> http://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-TIMEZONES
> Another issue to keep in mind is that in POSIX time zone names,
> positive offsets are used for locations west of Greenwich.
Yeah, we're caught between two incompatible convent
que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Sun, 29 Nov 2009 15:08:01 +0800
> From: seil...@so-net.net.tw
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] Time zone 'GMT+8'
>From
>http://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-TIMEZONES
Another issue to keep in mind is that in POSIX time zone names,
positive offsets are used for locations west of Greenwich.
On Sun, Nov 29, 2009 at 2:08 AM, wrote:
> The target pgsql is compiled fr
The target pgsql is compiled from 8.4rc1. 'GMT+8' can be found in installed
binary file .../share/postgresql/timezone/Etc/GMT+8.
This is the recorded script:
-BEGIN record--
db1=# select now();
now
---
2009-11-29 14:44:37.32241
On Fri, Oct 02, 2009 at 08:32:50PM +0100, Simon Riggs wrote:
>
> On Wed, 2009-09-30 at 23:48 -0500, Training wrote:
>
> > A training seminar that will put more time back in your life.
>
> Attending PostgreSQL training will help you to target your
> prospective customers more effectively and sto
On Wed, 2009-09-30 at 23:48 -0500, Training wrote:
> A training seminar that will put more time back in your life.
Attending PostgreSQL training will help you to target your prospective
customers more effectively and stop wasting their time in the first
place.
--
Simon Riggs www.2
A training seminar that will put more time back in your life.
A training provider registered with Services SETA
Presented by South Africa's leading Speakers
Dr Brian Jude and Associates present
MORE HOURS IN YOUR DAY
(Time management)
A Dynamic Morning Seminar
Time is a unique resourc
John Smithus writes:
> [ 'HADT' is not recognized as a timezone abbreviation ]
> The server is running PostgreSQL 8.3.7 on an AMD64 Gentoo Linux
> machine. The system time zone is set to 'America/Adak' and datestyle
> is set to 'sql, mdy' in postgresql.conf.
Not every timezone abbreviation in the
Greetings!
I'm encountering an "invalid input syntax for type timestamp" error in
a trigger.
The server is running PostgreSQL 8.3.7 on an AMD64 Gentoo Linux
machine. The system time zone is set to 'America/Adak' and datestyle
is set to 'sql, mdy' in postgresql.conf.
The target column type is "ti
On Mar 23, 2009, at 5:44 AM, Brad Murray wrote:
My current procedure...
1) Create temporary table with each possible data point. This
example uses
recursive functions from pgsql 8.4 but was originally implemented by
using
large numbers of queries from php. My knowledge of the recursive
f
I'm wanting to optimize and improve a query to get the maximum number of
users over a period of time. What I'm trying to accomplish is to get
graphable data points of the maximum number of simultaneous users at a
specified interval over a period of time, preferably with only a single pass
through
On Tue, Dec 2, 2008 at 10:37 AM, Andreas Kraftl
<[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> is it possible to get the time without the seconds and without the usage
>
> of a formatting function?
regexp and/or date_trunc
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
Hello,
is it possible to get the time without the seconds and without the usage
of a formatting function?
Example:
CREATE TABLE test.testtime
(
thetime time without time zone
);
INSERT INTO test.testtime (thetime) VALUES ('12:34:56');
INSERT INTO test.testtime (thetime) VALUES ('23:45');
SELECT
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Maybe we should just agree that its argument is a pattern for the
>> castsource type's name?
> I'd say it could be a pattern for both source and target. Often times I
> am interested in casts in either direction.
Well, it makes t
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Could we change the data types of the pg_cast table to regprocedure and
> regtype instead?
Back when we first introduced the reg-foo types, there was some
discussion of changing all relevant catalog columns to those types,
but the idea crashed and bu
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Tom Lane escribi�:
regression=# select casttarget::regtype,castcontext,castfunc::regprocedure from
pg_cast where castsource = 'time'::regtype;
BTW it very much looks like we should have a pg_casts view that displays
these things in
Alvaro Herrera wrote:
Tom Lane escribió:
However, the interval version of the function can capture the time case
because there's an implicit cast from time to interval:
regression=# select casttarget::regtype,castcontext,castfunc::regprocedure from
pg_cast where castsource = 'time'::regtype;
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> There already is a \dC command in psql, which has nice enough output
>> format but doesn't provide any way to select a subset of the table.
>> Maybe we should just agree that its argument is a pattern for the
>> castsource type's n
Andreas Kretschmer replied:
> I wrote:
> > How about doing:
> >
> > SELECT justify_interval(90061 * '1 second'::INTERVAL);
>
> Nice, didn't know this function.
Yup, PG does everything! Not sure when I discovered it; also not sure
if I've ever had to use it in anger before. I am, however, sli
Sam Mason <[EMAIL PROTECTED]> schrieb:
> On Tue, Nov 04, 2008 at 05:06:37PM +, Joao Ferreira gmail wrote:
> > I've been searching the docs on a simple way to convert a time
> > _duration_ in seconds to the format dd:hh:mm:ss, but I can't find it.
> >
> > 90061 --> 1d 1h 1m 1s
> >
> > (90061=
am Tue, dem 04.11.2008, um 17:06:37 + mailte Joao Ferreira gmail folgendes:
> Hello,
>
> I've been searching the docs on a simple way to convert a time
> _duration_ in seconds to the format dd:hh:mm:ss, but I can't find it.
>
> 90061 --> 1d 1h 1m 1s
>
> (90061=24*3600+3600+60+1)
>
> any id
On Tue, Nov 04, 2008 at 05:06:37PM +, Joao Ferreira gmail wrote:
> I've been searching the docs on a simple way to convert a time
> _duration_ in seconds to the format dd:hh:mm:ss, but I can't find it.
>
> 90061 --> 1d 1h 1m 1s
>
> (90061=24*3600+3600+60+1)
>
> any ideas ?
>
> I've been usi
On Tue, Nov 4, 2008 at 10:53 AM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 4, 2008 at 10:06 AM, Joao Ferreira gmail
> <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> I've been searching the docs on a simple way to convert a time
>> _duration_ in seconds to the format dd:hh:mm:ss, but I can'
On Tue, Nov 4, 2008 at 10:06 AM, Joao Ferreira gmail
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've been searching the docs on a simple way to convert a time
> _duration_ in seconds to the format dd:hh:mm:ss, but I can't find it.
>
> 90061 --> 1d 1h 1m 1s
>
> (90061=24*3600+3600+60+1)
select number*
Hello,
I've been searching the docs on a simple way to convert a time
_duration_ in seconds to the format dd:hh:mm:ss, but I can't find it.
90061 --> 1d 1h 1m 1s
(90061=24*3600+3600+60+1)
any ideas ?
I've been using to_char and to_timestamp to format dates/timestamps...
but this is diferent...
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane escribi�:
> >> regression=# select casttarget::regtype,castcontext,castfunc::regprocedure
> >> from pg_cast where castsource = 'time'::regtype;
>
> > BTW it very much looks like we should have a pg_casts view that displa
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> regression=# select casttarget::regtype,castcontext,castfunc::regprocedure
>> from pg_cast where castsource = 'time'::regtype;
> BTW it very much looks like we should have a pg_casts view that displays
> these things in a human-re
Tom Lane escribió:
> However, the interval version of the function can capture the time case
> because there's an implicit cast from time to interval:
>
> regression=# select casttarget::regtype,castcontext,castfunc::regprocedure
> from pg_cast where castsource = 'time'::regtype;
>castta
Bill Moran <[EMAIL PROTECTED]> writes:
> Not quite. As shown in the examples, date_trunc() works fine on
> TIME WITHOUT TIME ZONE, but there's no such function for TIME WITH
> TIME ZONE.
Well, actually there's no date_trunc for time either:
regression=# \df date_trunc
In response to "Scott Marlowe" <[EMAIL PROTECTED]>:
> On Mon, Nov 3, 2008 at 12:25 PM, Bill Moran
> <[EMAIL PROTECTED]> wrote:
> > In response to "Scott Marlowe" <[EMAIL PROTECTED]>:
> >
> >> On Mon, Nov 3, 2008 at 12:01 PM, Bill Moran
> >> <[EMAIL PROTECTED]> wrote:
> >> >
> >> > I'm trying to te
On Mon, Nov 3, 2008 at 12:31 PM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 3, 2008 at 12:25 PM, Bill Moran
> <[EMAIL PROTECTED]> wrote:
>> In response to "Scott Marlowe" <[EMAIL PROTECTED]>:
>>
>>> On Mon, Nov 3, 2008 at 12:01 PM, Bill Moran
>>> <[EMAIL PROTECTED]> wrote:
>>> >
>>> > I
On Mon, Nov 3, 2008 at 12:25 PM, Bill Moran
<[EMAIL PROTECTED]> wrote:
> In response to "Scott Marlowe" <[EMAIL PROTECTED]>:
>
>> On Mon, Nov 3, 2008 at 12:01 PM, Bill Moran
>> <[EMAIL PROTECTED]> wrote:
>> >
>> > I'm trying to test the time in a time column to see if it's the same
>> > minute as t
In response to "Scott Marlowe" <[EMAIL PROTECTED]>:
> On Mon, Nov 3, 2008 at 12:01 PM, Bill Moran
> <[EMAIL PROTECTED]> wrote:
> >
> > I'm trying to test the time in a time column to see if it's the same
> > minute as the current time. I wouldn't have thought this would be
> > difficult:
> >
> >
On Mon, Nov 3, 2008 at 12:01 PM, Bill Moran
<[EMAIL PROTECTED]> wrote:
>
> I'm trying to test the time in a time column to see if it's the same
> minute as the current time. I wouldn't have thought this would be
> difficult:
>
> WHERE TO_CHAR(now(), 'HH24MI') = TO_CHAR(time_column, 'HH24MI')
Use
On 03/11/2008 19:01, Bill Moran wrote:
> It seems as if EXTRACT() will work, but it sure feels hacky
> to do:
>
> (extract(hours from now()) = extract(hours from time_column)
> AND
> (extract(minutes from now()) = extract(minutes from time_column)
I'd have thought that this was the correct way
I'm trying to test the time in a time column to see if it's the same
minute as the current time. I wouldn't have thought this would be
difficult:
WHERE TO_CHAR(now(), 'HH24MI') = TO_CHAR(time_column, 'HH24MI')
Doesn't work, though:
ERROR: function to_char(time with time zone, unknown) does not
Adam Rich <[EMAIL PROTECTED]> writes:
> I traced a bug in our application down to this basic operation:
> set timezone to 'US/Eastern';
> select '11/02/2008'::timestamptz, '12:10'::time,
> '11/02/2008'::timestamptz + '12:10'::time;
> I have a date and a time stored separately and I want to combin
I traced a bug in our application down to this basic operation:
set timezone to 'US/Eastern';
select '11/02/2008'::timestamptz, '12:10'::time,
'11/02/2008'::timestamptz + '12:10'::time;
I have a date and a time stored separately and I want to combine them,
and use them in some timezone-aware cal
> If I make changes to the postgresql.conf and then do a 'pg_ctl reload', how
> do I get the date & time of this event?
it will be added in 8.4:
http://www.depesz.com/index.php/2008/05/05/waiting-for-84-pg_conf_load_time-time-related-generate_series-and-enum-values-in-dt/
depesz
--
Linkedin: h
Thank you Michael!
I have another question - related to this.
If I make changes to the postgresql.conf and then do a 'pg_ctl reload', how do
I get the date & time of this event?
Cheers!
Alexi Gen
On Mon, Aug 18, 2008 at 03:53:32AM -0700, Alexi Gen wrote:
> Is there a table/view available from
On Jan 8, 2008 8:51 AM, <[EMAIL PROTECTED]> wrote:
> DELETE from CONCURRENT_USER WHERE (now() - CONCURRENT_USER.TIME_STAMP) > ?
>
>
>
> Here the calculated value in '?' is not supported by the postgres as it was
> set as a double.
>
> I tried to cast it to a timestamp by using Timestamp timestamp
On Tue, Jan 08, 2008 at 08:21:40PM +0530, [EMAIL PROTECTED] wrote:
> The query is something like :
>
> DELETE from CONCURRENT_USER WHERE (now() - CONCURRENT_USER.TIME_STAMP) >
> ?
>
> Here the calculated value in '?' is not supported by the postgres as it
> was set as a double.
In postgres subtr
On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, January 08, 2008 8:52 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Time stamp issue
Importance: High
Hi Everyone,
I have a table named concurrent_user which has a column time_stamp. The
column stores the timestamp for the latest en
Hi Everyone,
I have a table named concurrent_user which has a column time_stamp. The
column stores the timestamp for the latest entered record.
My query finds the difference of the timestamp from the current time, if
the value is larger than 5 minutes then the latest entered record in the
tab
On Oct 5, 2007, at 9:10 AM, Kenneth Downs wrote:
I also found it very hard to pin down the penalty of the trigger,
but came up with rough figures of 30-50% overhead. The complexity
of the trigger did not matter.
in which language did you write your triggers?
---(
Jan Theodore Galkowski wrote:
Does anyone know, or can anyone point to information about how much
triggers penalize inserts in PG tables? I'm getting a report that it is
substantial, and before I investigate more. The triggers in question
look like:
I use triggers everywhere. About a year
On 10/4/07, Jan Theodore Galkowski <[EMAIL PROTECTED]> wrote:
> Does anyone know, or can anyone point to information about how much
> triggers penalize inserts in PG tables? I'm getting a report that it is
> substantial, and before I investigate more.
Using your DDL, with slight variations, I cam
Does anyone know, or can anyone point to information about how much
triggers penalize inserts in PG tables? I'm getting a report that it is
substantial, and before I investigate more. The triggers in question
look like:
#
# CREATE OR REPLACE FUNCTION touch_lasttouched() RETURNS TRIGGER AS
$touch_
Alvaro Herrera wrote:
> novnov escribió:
>> I think I get the picture; this post is the closest to making sense to me (my
>> lack of understanding is the issue, obviously). But:
>>
>> What's the postgresql client, in a web app?
>>
>> When you write "The web app sets timezone='EST5EDT' and inserts
On Sep 11, 2007, at 2:48 AM, Gregory Stark wrote:
"Ron Johnson" <[EMAIL PROTECTED]> writes:
On 09/10/07 19:50, Tom Lane wrote:
This whole sub-thread actually is predicated on an assumption not
in evidence, which is that there is any browser anywhere that will
tell the http server timezone i
"Ron Johnson" <[EMAIL PROTECTED]> writes:
> On 09/10/07 19:50, Tom Lane wrote:
>
>> This whole sub-thread actually is predicated on an assumption not
>> in evidence, which is that there is any browser anywhere that will
>> tell the http server timezone information. I'm quite sure no such
>> thing
> > The browser may not know the setting, or may not tell it to you,
> > or you might not be able to make any sense of what it says
> > (timezone names are hardly standardized).
>
> Well that's true. Except for numeric offsets.
Offsets aren't good enough due to changing DST rules. A current
offs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/10/07 19:50, Tom Lane wrote:
> Ron Johnson <[EMAIL PROTECTED]> writes:
>> On 09/10/07 15:21, Alvaro Herrera wrote:
>>> I wouldn't trust the browser's TZ, and you would need a way to
>>> override it.
>
>> Why?
>
> The browser may not know the se
Ron Johnson <[EMAIL PROTECTED]> writes:
> On 09/10/07 15:21, Alvaro Herrera wrote:
>> I wouldn't trust the browser's TZ, and you would need a way to
>> override it.
> Why?
The browser may not know the setting, or may not tell it to you,
or you might not be able to make any sense of what it says
(
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/10/07 15:21, Alvaro Herrera wrote:
[snip]
>
> I wouldn't trust the browser's TZ, and you would need a way to
> override it.
Why?
- --
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goe
novnov escribió:
>
> I think I get the picture; this post is the closest to making sense to me (my
> lack of understanding is the issue, obviously). But:
>
> What's the postgresql client, in a web app?
>
> When you write "The web app sets timezone='EST5EDT' and inserts a time of
> '2007-07-11 12
On Mon, Sep 10, 2007 at 12:44:04PM -0700, novnov wrote:
> What's the postgresql client, in a web app?
Your webapp *is* the postgresql client. The client is whatever opens
the connection to the server.
> When you write "The web app sets timezone='EST5EDT' and inserts a time of
> '2007-07-11 12:30:
I think I get the picture; this post is the closest to making sense to me (my
lack of understanding is the issue, obviously). But:
What's the postgresql client, in a web app?
When you write "The web app sets timezone='EST5EDT' and inserts a time of
'2007-07-11 12:30:00'." that's the black box th
1 - 100 of 209 matches
Mail list logo
