Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Can I add TODO items for this:
> > o Make CURRENT_TIMESTAMP/now() return statement start time
> > o Add TRANSACTION_TIMESTAMP to return transaction start time
>
> I object to both of those as phrased. If you have already uni
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can I add TODO items for this:
> o Make CURRENT_TIMESTAMP/now() return statement start time
> o Add TRANSACTION_TIMESTAMP to return transaction start time
I object to both of those as phrased. If you have already unilaterally
determined the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was thinking 'transaction_timestamp' for the transaction start time, and
> > current_timestamp for the statement start time. I would equate now()
> > with current_timestamp.
>
> So you want to both (a) invent even more nonstandard
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was thinking 'transaction_timestamp' for the transaction start time, and
> current_timestamp for the statement start time. I would equate now()
> with current_timestamp.
So you want to both (a) invent even more nonstandard syntax than we
already have
Alvaro Herrera wrote:
> Bruce Momjian dijo:
>
> > Roberto Mello wrote:
>
> > > Forgive my ignorance here, but what is GUC? And how would I access the
> > > query duration?
> >
> > GUC is postgresql.conf and SET commands. They are variables that can be
> > set.
>
> Just for the record, GUC is
John Hasler wrote:
> Bruce Momjian writes:
> > My point is that our current behavior may not be the most intuitive, and
> > that most people may prefer a change.
>
> I would prefer a change.
Yes, I guess that is my point, that we want to make transaction _and_
statement timestamp values availabl
Bruce Momjian writes:
> My point is that our current behavior may not be the most intuitive, and
> that most people may prefer a change.
I would prefer a change.
--
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin
---(end of broadcast)-
Aaron,
> This database gets a monthly update and it read only until the next
> update. I ANALYZE once after each update. Since the data does not
> change I should not need to ANALYZE again afterwards.
Actually, if the database is read-only between updates, you should:
ANALYZE
VACUUM FULL F
Josh Berkus wrote:
>
> Tom, Bruce,
>
> > > A possible compromise is to dissociate now() and current_timestamp,
> > > allowing the former to be start of transaction and the latter to be
> > > start of client command.
> >
> > I was thinking 'transaction_timestamp' for the transaction start time,
Tom, Bruce,
> > A possible compromise is to dissociate now() and current_timestamp,
> > allowing the former to be start of transaction and the latter to be
> > start of client command.
>
> I was thinking 'transaction_timestamp' for the transaction start time, and
> current_timestamp for the sta
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I see what you are saying now --- that even single user statements can
> > trigger multiple statements, so you would have to say transaction start
> > time is time the user query starts. I can see how that seems a little
> > arbitrar
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I see what you are saying now --- that even single user statements can
> trigger multiple statements, so you would have to say transaction start
> time is time the user query starts. I can see how that seems a little
> arbitrary. However, don't we have
Roberto Mello wrote:
> On Mon, Sep 23, 2002 at 10:48:30AM -0400, Bruce Momjian wrote:
> > > > >
> > > > > Would it be a good idea to add the time that the current query began
> > > > > execution at to pg_stat_activity?
> > > >
> > > > What do people think about this? It seems like a good idea t
I see what you are saying now --- that even single user statements can
trigger multiple statements, so you would have to say transaction start
time is time the user query starts. I can see how that seems a little
arbitrary. However, don't we have separate paths for user queries and
queries sent
On Mon, Sep 23, 2002 at 10:48:30AM -0400, Bruce Momjian wrote:
> > > >
> > > > Would it be a good idea to add the time that the current query began
> > > > execution at to pg_stat_activity?
> > >
> > > What do people think about this? It seems like a good idea to me.
> >
> > OpenACS has a pack
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see how we can defend returning the start of the transaction as
> the current_timestamp.
Here's an example:
CREATE RULE foo AS ON INSERT TO mytable DO
( INSERT INTO log1 VALUES (... , now(), ...);
INSERT INTO log2 VALUES (... , now(), ...) );
Josh Berkus wrote:
>
> Bruce,
>
> > I don't see how we can defend returning the start of the transaction as
> > the current_timestamp. In a multi-statement transaction, that doesn't
> > seem very current to me. I know there are some advantages to returning
> > the same value for all queries in
Bruce,
> I don't see how we can defend returning the start of the transaction as
> the current_timestamp. In a multi-statement transaction, that doesn't
> seem very current to me. I know there are some advantages to returning
> the same value for all queries in a transaction, but is that value
Josh Berkus wrote:
> I, for one, would judge that the start time of the statement is "during the
> execution"; it would only NOT be "during the execution" if it was a value
> *before* the start time of the statement. It's a semantic argument.
>
> The spec is, IMHO, rather vague on how this wou
Manfred,
> C2: The returned value has to represent a point in time *during* the
> execution of the SQL-statement.
>
> The only thing an implementor is free to choose is which point in time
> "during the execution of the SQL-statement" is to be returned, i.e. a
> timestamp in the interval betwee
On Mon, 23 Sep 2002 13:05:42 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Manfred Koizar <[EMAIL PROTECTED]> writes:
>> This has been discussed before and I know I'm going to get flamed for
>> this, but IMHO having now() (which is a synonym for CURRENT_TIMESTAMP)
>> return the start time of the cur
Manfred Koizar <[EMAIL PROTECTED]> writes:
> This has been discussed before and I know I'm going to get flamed for
> this, but IMHO having now() (which is a synonym for CURRENT_TIMESTAMP)
> return the start time of the current transaction is a bug, or at least
> it is not conforming to the standar
On Mon, 23 Sep 2002 11:06:19 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>Tom Lane wrote:
>> It would be nearly free to include the start time of the current
>> transaction, because we already save that for use by now(). Is
>> that good enough, or do we need start time of the current qu
Hi all,
I just read it's possible to get the MVCC last version numbers. Is it also
possible to get the current transaction id? Would it be possible to check
later if that transaction has been commited? This would be nice for a distributed
application to enforce an "exactly once" semantics for tra
That is great! Thanks for the info.
Tom Lane wrote:
>
> Jean-Luc Lachance <[EMAIL PROTECTED]> writes:
> > How about making available the MVCC last version number just like oid is
> > available. This would simplify a lot of table design. You know, having
> > to add a field "updated::timestamp"
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, added to TODO:
> > * Add start time to pg_stat_activity
>
> It would be nearly free to include the start time of the current
> transaction, because we already save that for use by now(). Is
> that good enough, or do we need
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, added to TODO:
> * Add start time to pg_stat_activity
It would be nearly free to include the start time of the current
transaction, because we already save that for use by now(). Is
that good enough, or do we need start time of the current qu
Aaron Held wrote:
> It looks like that just timestamps things in its connection pool, that
> is what I do now.
>
> What I would like is to know about queries that have not finished yet.
OK, added to TODO:
* Add start time to pg_stat_activity
Should we supply the current duration too?
Roberto Mello wrote:
> On Sun, Sep 22, 2002 at 09:51:55PM -0400, Bruce Momjian wrote:
> > >
> > > Would it be a good idea to add the time that the current query began
> > > execution at to pg_stat_activity?
> >
> > What do people think about this? It seems like a good idea to me.
>
> OpenACS h
It looks like that just timestamps things in its connection pool, that
is what I do now.
What I would like is to know about queries that have not finished yet.
-Aaron
Roberto Mello wrote:
> On Sun, Sep 22, 2002 at 09:51:55PM -0400, Bruce Momjian wrote:
>
>>>Would it be a good idea to add the
=?iso-8859-1?Q?Thorbj=F6rn_Eriksson?= <[EMAIL PROTECTED]> writes:
> Thank's Tom Lane & Stephan Szabo for pointing out the problem to me.
> After some testing it turned out that the swedish locale, 'sv_SE', doesn't
> handle sorting spaces as expected, which probably made the SELECT fail. On
> the o
Thank's Tom Lane & Stephan Szabo for pointing out the problem to me.
After some testing it turned out that the swedish locale, 'sv_SE', doesn't
handle sorting spaces as expected, which probably made the SELECT fail. On
the other hand, if I use the 'C' locale, the SELECT works but not the sort
ord
On Sun, Sep 22, 2002 at 09:51:55PM -0400, Bruce Momjian wrote:
> >
> > Would it be a good idea to add the time that the current query began
> > execution at to pg_stat_activity?
>
> What do people think about this? It seems like a good idea to me.
OpenACS has a package called "Developer Suppor
I am running pg 7.2 the PG reference build.
Thanks for the ANALYZE tip, it led me to a answer.
This database gets a monthly update and it read only until the next
update. I ANALYZE once after each update. Since the data does not
change I should not need to ANALYZE again afterwards.
I menti
Bruce Momjian wrote:
> Neil Conway wrote:
>
>>Bruce Momjian <[EMAIL PROTECTED]> writes:
>>
>>>Aaron Held wrote:
>>>
Is there any way to monitor a long running query?
>>>
>>>Oh, sorry, you want to know how far the query has progressed. Gee, I
>>>don't think there is any easy way to do that.
>
35 matches
Mail list logo
