On Tue, May 09, 2006 at 05:16:57PM -0400, Rocco Altier wrote:
> > - To get this close it needs to get an estimate of the sampling
> > overhead. It does this by a little calibration loop that is run
> > once per backend. If you don't do this, you end up assuming all
> > tuples take the same time as
> - To get this close it needs to get an estimate of the sampling
overhead.
> It does this by a little calibration loop that is run once per
backend.
> If you don't do this, you end up assuming all tuples take the same
time
> as tuples with the overhead, resulting in nodes apparently taking
> longe
On Tue, 2006-05-09 at 22:37 +0200, Martijn van Oosterhout wrote:
> This was a suggestion made back in March that would dramatically reduce
> the overhead of EXPLAIN ANALYZE on queries that loop continuously over
> the same nodes.
>
> http://archives.postgresql.org/pgsql-hackers/2006-03/msg01114.ph
This was a suggestion made back in March that would dramatically reduce
the overhead of EXPLAIN ANALYZE on queries that loop continuously over
the same nodes.
http://archives.postgresql.org/pgsql-hackers/2006-03/msg01114.php
What it does behave normally for the first 50 tuples of any node, but
af
Dear Tom,
I think that the inability to convert nearly binary compatible standard
types one to the other is a postgresql issue. Even if it is not often
useful, the point is completeness and soundness of the type provided by
the core.
OK, can I get some feedback from others about this patch?
On Tue, May 09, 2006 at 11:35:32AM -0400, Bruce Momjian wrote:
> > So at the end of configure the user can visually confirm
> > his expectations without needing to parse the noise
> > from full configure output. Maybe this would be better
> > solution.
>
> Seems we would be best printing out opti
From: "Tom Lane" <[EMAIL PROTECTED]>
> What is the point of this? It seems to be complicating life to little
> purpose (except storing passwords that will fail in non-MD5 password
> methods --- given that people are talking about replacing MD5, that
> doesn't seem like a good forward-looking idea
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
> I may be quite persistent.:-)
> I seasoned the proposal method. It was very painful that the
> conventional connection method to this password was a plain text.
> Although I am simple, I desire the support. Furthermore, the relation
> between a field
Marko Kreen wrote:
> On 5/9/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout:
> > > 1. Provide an escape option they can add
> > > 2. Package systems can usually apply patches prior to compiling, they can
> > > always remove the offend
On Tue, May 09, 2006 at 09:18:17AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Eh? It stops a program expecting libpq4 being linked to libpq3 for any
> > reason, so the above situation can't happen. You don't need to version
> > any structs, only the functions using them.
>
> If w
Dear Bruce san.
I may be quite persistent.:-)
I seasoned the proposal method. It was very painful that the
conventional connection method to this password was a plain text.
Although I am simple, I desire the support. Furthermore, the relation
between a field item and an environment variable is c
Dhanaraj M <[EMAIL PROTECTED]> writes:
> However, it was not possible to display the seq. value using this.
> Hence, I made a small change in the currval() function, so that it
> retrieves the last_value
> even if the the value is not cached.
Breaking currval()'s semantics is not an acceptable so
Martijn van Oosterhout writes:
> Eh? It stops a program expecting libpq4 being linked to libpq3 for any
> reason, so the above situation can't happen. You don't need to version
> any structs, only the functions using them.
If we have an existing app built against an unversioned libpq, what
happen
On Tue, May 09, 2006 at 01:50:38PM +0200, Peter Eisentraut wrote:
> Am Dienstag, 9. Mai 2006 10:41 schrieb Martijn van Oosterhout:
> > Depends what you mean by signature. The structures of PGconn and
> > PGresult have changed over time, so if you you pass a PGresult
> > allocated by libpq4 to a fun
Am Dienstag, 9. Mai 2006 10:55 schrieb Martijn van Oosterhout:
> Can you explain why? Unknown options don't do anything, so having users
> remove them seems like a good move.
Build system frameworks assume that they can pass any option and that unknown
options will be ignored. This grew out of t
Am Dienstag, 9. Mai 2006 10:41 schrieb Martijn van Oosterhout:
> Depends what you mean by signature. The structures of PGconn and
> PGresult have changed over time, so if you you pass a PGresult
> allocated by libpq4 to a function in libpq3, it'll crash.
Symbol versioning only affects functions (a
Bruce Momjian wrote:
I am thinking we just add another column to the \d display for sequences
showing the current value.
---
As suggested in the previous mails, I tried to use the following to
display the seq. value.
Yep, the pipe.c patch is unnecessary now.
Pete
>>> Bruce Momjian 05/07/06 3:44 am >>>
Now that we know the cause of the Win32 failure (FRONTEND), we don't
need the Win32 part of this patch anymore right?
---(end of broadcast)---
TIP 5: don't forge
On Tue, May 09, 2006 at 10:37:43AM +0200, Peter Eisentraut wrote:
> Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout:
> > 1. Provide an escape option they can add
> > 2. Package systems can usually apply patches prior to compiling, they can
> > always remove the offending line if they l
On 5/9/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout:
> 1. Provide an escape option they can add
> 2. Package systems can usually apply patches prior to compiling, they can
> always remove the offending line if they like.
> 3. Try and
On Tue, May 09, 2006 at 10:19:56AM +0200, Peter Eisentraut wrote:
> Am Samstag, 29. April 2006 21:27 schrieb Martijn van Oosterhout:
> > What it does is remove the restriction that any one program can only
> > use (directly or indirectly) one version of libpq at any moment.
> > Programs can use ind
Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout:
> 1. Provide an escape option they can add
> 2. Package systems can usually apply patches prior to compiling, they can
> always remove the offending line if they like.
> 3. Try and get feedback from them now rather than wait
My feedback
Am Samstag, 29. April 2006 21:27 schrieb Martijn van Oosterhout:
> What it does is remove the restriction that any one program can only
> use (directly or indirectly) one version of libpq at any moment.
> Programs can use indirectly postgres via PAM or NSS or other such
> pluggable interfaces. Curr
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrus
> Sent: 08 May 2006 18:16
> To: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] Adminpack contrib module
>
> > There were no objections, so attached is an updated version of t
24 matches
Mail list logo
