On Tue, Aug 01, 2006 at 04:25:00PM -0400, Christopher Browne wrote:
> ?column? | setting
> --+-
> 5432 | 7.4.13
> (1 row)
>
> ?column? | setting
> --+-
> 5533 | 7.4.10
> (1 row)
>
> ?column? | setting
> --+-
> 5532 | 8.0.5
> (1
Joe Conway wrote:
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete.
I checked out memory usage, and it
Anyway, with the attached diff, the 2 million inserts case is back to
about 730 MB memory use, and speed is pretty much the same as reported
yesterday (i.e both memory use and performance better than mysql with
innodb tables).
That's all that matters ;)
Joshua D. Drake
--
=== The Postg
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete.
I checked out memory usage, and it had regressed to ab
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
I don't recall that anyone agreed to do anything in particular, let
alone the process being formalized thus.
Bruce was looking for there to be some form of overview of the free
replication options so he'd
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Is this intentional:
> template1=# values(1), (2);
> column1
> -
>1
>2
> (2 rows)
You bet. VALUES is parallel to SELECT in the SQL grammar, so AFAICS
it should be legal anywhere you can write SELECT.
The basic productions in th
[EMAIL PROTECTED] (Peter Eisentraut) wrote:
> Chris Browne wrote:
>> Here's a patch to add in the material on replication recently
>> discussed on pgsql.docs. I'm not thrilled that there were only a few
>> comments made; I'd be happy to see "slicing and dicing" to see this
>> made more useful.
>
>
Set tg_trigtuple/tg_newtuple in AFTER triggers according to whether
old and new tuples were supplied rather than blindly setting them
according to the event type. Per discussion in pgsql-hackers.
http://archives.postgresql.org/pgsql-hackers/2006-07/msg01601.php
If the patch is logically or styli
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete. I'm off to dinner again, it's in your court to look ove
On Tue, 1 Aug 2006, Joe Conway wrote:
> Gavin Sherry wrote:
> > Is this intentional:
> >
> > template1=# values(1), (2);
> > column1
> > -
> >1
> >2
> > (2 rows)
> >
> > This is legal because of:
> >
> > simple_select:
> > /* ... */
> > | values_clause
Gavin Sherry wrote:
Is this intentional:
template1=# values(1), (2);
column1
-
1
2
(2 rows)
This is legal because of:
simple_select:
/* ... */
| values_clause { $$ = $2; }
hmm, not sure about that...
Also, I am working out
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete. I'm off to dinner again, it's in your court to look ove
Joshua D. Drake wrote:
> Alvaro Herrera wrote:
> >Joshua D. Drake wrote:
> >
> >>>I don't think this sort of material belongs directly into the PostgreSQL
> >>>documentation.
> >
> >Why not?
>
> Well Peter said that, not me :)
I know, but I though I'd post one message instead of two. (In fact I
Alvaro Herrera wrote:
Joshua D. Drake wrote:
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
Why not?
Well Peter said that, not me :)
It might be interesting to have some links in the external projects area
for replication, but a section of its ow
Joshua D. Drake wrote:
> >I don't think this sort of material belongs directly into the PostgreSQL
> >documentation.
Why not?
> It might be interesting to have some links in the external projects area
> for replication, but a section of its own doesn't seem relevant.
I disagree about "having
1. post information on pgsql-general
1.a. solicit comments
2. put information page on web site
3. link from documentation to web site
You seem to have short-circuited all that.
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
It might be interesting to
Tom,
Is this intentional:
template1=# values(1), (2);
column1
-
1
2
(2 rows)
This is legal because of:
simple_select:
/* ... */
| values_clause { $$ = $2; }
Also, I am working out some docs and regression tests.
Gavin
--
Chris Browne wrote:
> Here's a patch to add in the material on replication recently
> discussed on pgsql.docs. I'm not thrilled that there were only a few
> comments made; I'd be happy to see "slicing and dicing" to see this
> made more useful.
The agreed-to process was
1. post information on pg
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete. I'm off to dinner again, it's in your court to look over some
more if you
Thanks for mentioning about pgpool!
> pgpool
>
> pgpool was initially created by
> Tatsuo Isshii as a portable alternative to Java connection pool
> modules. He subsequently observed that it wouldn't take very much
> effort to extend it to create a simple replication sy
s/sequnce/sequence/
Nice work!
--
Korry Douglas [EMAIL PROTECTED]
EnterpriseDB http://www.enterprisedb.com
Chris Browne wrote:
> Here's a patch to add in the material on replication recently
> discussed on pgsql.docs. I'm not thrilled that there were only a few
> comments made; I'd be happy to see "slicing and dicing" to see this
> made more useful.
s/e.g. -/e.g.,/
s/ - /–/
The indentation of the SGM
Quoth [EMAIL PROTECTED] (David Fetter):
> On Tue, Aug 01, 2006 at 12:37:48PM -0500, Jim C. Nasby wrote:
>> On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote:
>> > David Fetter <[EMAIL PROTECTED]> writes:
>> > > On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
>> > >> The correct sol
Here's a patch to add in the material on replication recently
discussed on pgsql.docs. I'm not thrilled that there were only a few
comments made; I'd be happy to see "slicing and dicing" to see this
made more useful.
Index: filelist.sgml
===
I updated the style of your patch, and added a little to your comment
block about how to use this capability. I don't think any additional
documentation is necessary.
Thanks.
---
Marc Munro wrote:
-- Start of PGP signed
Pavel Stehule wrote:
Hello,
I send two small patches. First does conversion from perl to
postgresql array in OUT parameters. Second patch allow hash form
output from procedures with one OUT argument.
I will try to review these in the next 2 weeks unless someone beats me
to it.
cheers
a
Greg Sabino Mullane wrote:
-- Start of PGP signed section.
> Here's the latest pg_dump patch I've been (too sporadically) working on.
> I abandoned building linked lists and decided to make the backend do all
> the work, from building the list of good relations, to doing the POSIX
> regex matching.
On Tue, Aug 01, 2006 at 12:37:48PM -0500, Jim C. Nasby wrote:
> On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote:
> > David Fetter <[EMAIL PROTECTED]> writes:
> > > On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
> > >> The correct solution is for client-side libraries to provide
On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
> >> The correct solution is for client-side libraries to provide the
> >> feature.
>
> > Not if the app is written in SQL, as the boot
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Would this do the trick?
I think Bruce changed the call convention for run_diff ... are you
looking at CVS tip? Otherwise it looks reasonable.
You're right. I had forgotten to do a cvs update. Fixed and committed.
cheer
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Would this do the trick?
I think Bruce changed the call convention for run_diff ... are you
looking at CVS tip? Otherwise it looks reasonable.
regards, tom lane
---(end of broadcast)
Hello,
I send two small patches. First does conversion from perl to postgresql
array in OUT parameters. Second patch allow hash form output from procedures
with one OUT argument.
Regards
Pavel Stehule
_
Citite se osamele? Poznej
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
One other thought I had was that we could have
pg_regress always allow a fallback to the canonical result file.
Hm, that's a good thought. Want to see how painful it is to code?
Would this do the trick?
cheers
andrew
Joe Conway <[EMAIL PROTECTED]> writes:
> In case you can make use of it, here's my latest. I found that I was
> being too aggressive at freeing the input nodes to transformExpr() in
> transformRangeValues() after using them. In many cases the returned node
> is a new palloc'd node, but in some c
On 01/08/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Maybe we need to abandon trying to map float8 results exactly in the
> resultmap file, and just let pg_regress pick the best fit as we do with
> some other tests.
I thought about that too but it seems a
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Maybe we need to abandon trying to map float8 results exactly in the
> resultmap file, and just let pg_regress pick the best fit as we do with
> some other tests.
I thought about that too but it seems a very bad idea. small-is-zero is
distinctly "les
[ re cassowary buildfarm failure ]
"Adrian Maier" <[EMAIL PROTECTED]> writes:
> On 20/07/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> As for the regression test failure, it's odd because it looks to me that
>> the actual test output is an exact match to the default "float8.out"
>> file. I'm not sur
On 01/08/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Adrian Maier wrote:
> On 20/07/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Apparently the regression test is comparing the results/float8.out
> with expected/float8-small-is-zero.out because of the following line
> in
> src/test/regress/res
Adrian Maier wrote:
On 20/07/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Reini Urban <[EMAIL PROTECTED]> writes:
> BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is
defined also.
You sure? INT64_IS_BUSTED should *not* be set in that case --- it's
only supposed to be set if we couldn't
Albe Laurenz wrote:
> Tim Allen wrote:
> >>>Patch included to implement xlog switching, using an xlog record
> >>>"processing instruction" and forcibly moving xlog pointers.
> >>>
> >>>1. Happens automatically on pg_stop_backup()
> >>
> >>
> >> Oh - so it will not be possible to do an online back
On 20/07/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Reini Urban <[EMAIL PROTECTED]> writes:
> BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is defined also.
You sure? INT64_IS_BUSTED should *not* be set in that case --- it's
only supposed to be set if we couldn't find any 64-bit-int ty
Albe Laurenz wrote:
Tim Allen wrote:
Patch included to implement xlog switching, using an xlog record
"processing instruction" and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch
Tim Allen wrote:
>>>Patch included to implement xlog switching, using an xlog record
>>>"processing instruction" and forcibly moving xlog pointers.
>>>
>>>1. Happens automatically on pg_stop_backup()
>>
>>
>> Oh - so it will not be possible to do an online backup
>> _without_ forcing a WAL switch
Albe Laurenz wrote:
Simon Riggs wrote:
Patch included to implement xlog switching, using an xlog record
"processing instruction" and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL swi
Simon Riggs wrote:
> Patch included to implement xlog switching, using an xlog record
> "processing instruction" and forcibly moving xlog pointers.
>
> 1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch any more?
Lau
Joshua,> So now it's MySQL users' turn to say, "Sure, but speed isn't
> everything" :-)"Sure, but speed isn't everything... We can accept 02/31/2006 as a validdate. Let's see PostgreSQL do that!"I got the joke :)But: it is still a problem when converting. As accepting 2006-02-31 as a valid date
46 matches
Mail list logo
