Hi,
I have made patches to change the delta val from 0 and 1 to -5000
and 5000 per recent discussion in hackers list. Also I have enhanced
predefined benchmark scenarios to reflect the scaling factor parameter
flexibly.
If there's no objection, I will commit by the end of this week.
--
Tatsu
From: "Florian G. Pflug"
Ahhh, It is right.!
I was retracing my memory for what situations the contents were.
I was in distraction.It seems that it is satisfactory at the reason for ==.
Sorry and Thanks.!!
Regards,
Hiroshi Saito
Bruce Momjian wrote:
Why is this better than:
#if
[EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
Why is this better than:
#if _MSC_VER == 1400
Surely this will not be true if _MSC_VER is undefined?
I experienced injustice and the reason of in OSX for it.
What was the problem with OSX? Did it throw a warning of you did an
equality test on
> Bruce Momjian wrote:
Why is this better than:
#if _MSC_VER == 1400
Surely this will not be true if _MSC_VER is undefined?
>>> I experienced injustice and the reason of in OSX for it.
>>
>> What was the problem with OSX? Did it throw a warning of you did an
>> equa
Bruce Momjian wrote:
Why is this better than:
#if _MSC_VER == 1400
Surely this will not be true if _MSC_VER is undefined?
I experienced injustice and the reason of in OSX for it.
What was the problem with OSX? Did it throw a warning of you did an
equality test on an undefined symbol?
T
Ühel kenal päeval, K, 2006-07-26 kell 14:27, kirjutas Darcy Buskermolen:
> On Wednesday 26 July 2006 14:03, Tom Lane wrote:
> > Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> > >> The question though is if we did that, would Slony actually use it?
> > >
> > > If it made sence to do it, then yes we
Darcy Buskermolen wrote:
> On Wednesday 26 July 2006 14:03, Tom Lane wrote:
> > Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> > >> The question though is if we did that, would Slony actually use it?
> > >
> > > If it made sence to do it, then yes we would do it. The problem ends up
> > > being Sl
Ühel kenal päeval, K, 2006-07-26 kell 23:02, kirjutas Martijn van
Oosterhout:
> On Wed, Jul 26, 2006 at 12:47:57PM -0400, Greg Stark wrote:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >
> > > So far, the case hasn't been made for retail vacuum even ignoring the
> > > not-so-immutable-function risk.
On Wednesday 26 July 2006 14:03, Tom Lane wrote:
> Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> >> The question though is if we did that, would Slony actually use it?
> >
> > If it made sence to do it, then yes we would do it. The problem ends up
> > being Slony is designed to work across a mult
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am sure you worked hard on this, but I don't see the use case, nor
> > have I heard people in the community requesting such functionality.
> > Perhaps pgfoundry would be a better place for this.
>
> The part of this that would actu
Ühel kenal päeval, K, 2006-07-26 kell 13:35, kirjutas Bruce Momjian:
> I am sure you worked hard on this, but I don't see the use case,
The use case is any slony-like replication system or queueing system
which needs consistent means of knowing batches of transactions which
have finished during s
Ühel kenal päeval, K, 2006-07-26 kell 13:41, kirjutas Darcy Buskermolen:
> On Wednesday 26 July 2006 13:04, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I am sure you worked hard on this, but I don't see the use case, nor
> > > have I heard people in the community requesting
On Wed, Jul 26, 2006 at 12:47:57PM -0400, Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > So far, the case hasn't been made for retail vacuum even ignoring the
> > not-so-immutable-function risk.
>
> Well the desire for it comes from a very well established need for dealing
> with
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
>> The question though is if we did that, would Slony actually use it?
> If it made sence to do it, then yes we would do it. The problem ends up being
> Slony is designed to work across a multitude of versions of PG, and unless
> this was backported t
Susanne Ebrecht <[EMAIL PROTECTED]> writes:
> here is a patch that extends update syntax following the sql standard.
> The patch includes sgml documentation, too.
> UPDATE table SET (col1, col2, ...) = (val1, val2, ...),
> (colm, coln, ...) = (valm, valn, ...), ...;
This is a cute hack, but it do
On Wednesday 26 July 2006 13:04, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am sure you worked hard on this, but I don't see the use case, nor
> > have I heard people in the community requesting such functionality.
> > Perhaps pgfoundry would be a better place for this.
>
> T
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am sure you worked hard on this, but I don't see the use case, nor
> have I heard people in the community requesting such functionality.
> Perhaps pgfoundry would be a better place for this.
The part of this that would actually be useful to put in cor
Joachim Wieland wrote:
Zdenek,
The general idea (at least my idea) is that
whenever a SIGHUP is received and there is some difference between the
config file and the active value that the server is using, a notice message
is written to the log. That way, at every moment you can see if the active
I am sure you worked hard on this, but I don't see the use case, nor
have I heard people in the community requesting such functionality.
Perhaps pgfoundry would be a better place for this.
---
Marko Kreen wrote:
>
> Intro
Patch attached and applied. Thanks.
---
Hiroshi Saito wrote:
> Hi.
>
> "William ZHANG" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> > When I tried to compile pgsql-8.2devel with VS.Net 2005 and do regressi
Hiroshi Saito wrote:
> From: "Andrew Dunstan"
>
> > Hiroshi Saito wrote:
> > > Hmm, It seems to be the bug of very unpleasant Microsoft.:D
> > > I think that the following is desirable as an evasion measure to add.
> > >
> > > #if defined(_MSC_VER) && _MSC_VER == 1400
> > >
> > > To be sure, it w
Tom Lane <[EMAIL PROTECTED]> writes:
> So far, the case hasn't been made for retail vacuum even ignoring the
> not-so-immutable-function risk.
Well the desire for it comes from a very well established need for dealing
with extremely large tales with relatively small hot spots. The basic problem
b
Albe Laurenz wrote:
> Bruce Momjian wrote:
> > Albe Laurenz wrote:
> >> This patch for libpq allows you to enter an LDAP URL in
> pg_service.conf.
> >> The URL will be queried and the resulting string(s) parsed for
> >> keyword = value connection options.
> >
> > I have heavily modified your patch
Csaba Nagy <[EMAIL PROTECTED]> writes:
>> [snip] (In fact, it's
>> trivial to see how user-defined functions that are mislabeled immutable
>> could make this fail.) So retail vacuum without any cross-check that
>> you got all the index tuples is a scary proposition IMHO.
> Wouldn't work to restri
> [snip] (In fact, it's
> trivial to see how user-defined functions that are mislabeled immutable
> could make this fail.) So retail vacuum without any cross-check that
> you got all the index tuples is a scary proposition IMHO.
Wouldn't work to restrict that kind of vacuum to only tables which h
Bruce Momjian wrote:
> Albe Laurenz wrote:
>> This patch for libpq allows you to enter an LDAP URL in
pg_service.conf.
>> The URL will be queried and the resulting string(s) parsed for
>> keyword = value connection options.
>
> I have heavily modified your patch to be clearer. Please review the
>
Gregory Stark <[EMAIL PROTECTED]> writes:
> ... Well it's not like the existing vacuum checks for this.
Right, that's exactly why the patch works at all. But the point here is
that the existing vacuum does not rely on re-computing index keys; all
it cares about is matching TIDs. The retail-vacuu
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> This patch is nowhere near ready for submission :-(. Most of the
>> comments seem to be "I don't know what to do here" ...
> Just to be clear, I think what Tom's saying it's not ready to be *applied*.
> Sending pa
Tom Lane <[EMAIL PROTECTED]> writes:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > This is a revised patch originated by Junji TERAMOTO for HEAD.
> > [BTree vacuum before page splitting]
> > http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
> > I think we can resurrect hi
Tom Lane <[EMAIL PROTECTED]> writes:
> This patch is nowhere near ready for submission :-(. Most of the
> comments seem to be "I don't know what to do here" ...
Just to be clear, I think what Tom's saying it's not ready to be *applied*.
Sending patches to this list early and often during develop
Peter Eisentraut wrote:
Here is a preliminary patch for units in postgresql.conf (and SET and so on,
of course). It currently supports memory units only. Time units would be
similar. Let me know if you have comments.
The concept is good. However, parse should generate overflow. You
multipl
On Tue, Jul 25, 2006 at 10:37:20PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > I'll take a whack at that patch this evening PDT or tomorrow evening
> > at the latest. We're too late in the cycle to go over this, but maybe
> > we can figure out a way to have this data read
--On Dienstag, Juli 25, 2006 18:29:39 -0500 Jaime Casanova
<[EMAIL PROTECTED]> wrote:
On 7/25/06, Bernd Helmle <[EMAIL PROTECTED]> wrote:
Hi folks,
please find attached an implementation for updatable views. Included are
support for pg_dump and information_schema, regression test and
docum
33 matches
Mail list logo
