Dear Friends,
First, thank you very much for considering a fix on the GROUP BY issue.
I am starting a new thread about another issue:
It seems that DELETE cannot understand INNER JOINS and needs HAVING.
Read:
http://drupal.org/node/62 (main message)
http://drupal.org/node/555648
I don't s
Alvaro Herrera píše v pá 21. 08. 2009 v 17:48 -0400:
> Tom Lane wrote:
>
> > I'd still like to have some fork-rate-limiting behavior in there
> > somewhere. However, it might make sense for the avlauncher to do that
> > rather than the postmaster. Does that idea seem more implementable?
>
>
Tom Lane píše v pá 21. 08. 2009 v 18:06 -0400:
> Maybe, but I think we need to understand exactly what happened first.
I try to mine more data from the system to reconstruct what happen.
Unfortunately, default postgresql log configuration does not have
timestamp. The postgresql had no load, syst
As documented in the patch, the primary motivation was support of BYTEA
datatype, which when cast through cstring was truncating python strings with
embedded nulls,
performance was only a secondary consideration.
Regards,
Caleb
(Sorry for my slow entry on this thread, I'm on vacation right no
Tom Lane wrote:
Huh. As far as I can see this example should traverse the same code
path. I was about to ask for the dataset, but I think you might have
already sent it to me once --- does this look familiar?
$ tar tvfj geography.tar.bz2
-rw-r--r-- shade/shade 6444737 2008-06-06 13:33 geograp
On Sat, Aug 22, 2009 at 11:45 AM, Caleb Welton wrote:
> As documented in the patch, the primary motivation was support of BYTEA
> datatype, which when cast through cstring was truncating python strings with
> embedded nulls,
> performance was only a secondary consideration.
The alternative to atta
Gokulakannan Somasundaram writes:
>I have given some thought in this direction. I am just providing my idea.
> a) Have a structure similar to commit log, which should also store,
> transaction id at which the transaction got committed. Every transaction,
> after committing should update the t
Zdenek Kotala writes:
> There are most important records from yesterdays issues.
> Messages:
> -
> Aug 20 11:14:54 genunix: [ID 470503 kern.warning] WARNING: Sorry, no swap
> space to grow stack for pid 507 (postgres)
Hmm, that seems to confirm the idea that something had run the machin
Greg Stark writes:
> On Sat, Aug 22, 2009 at 11:45 AM, Caleb Welton wrote:
>> As documented in the patch, the primary motivation was support of BYTEA
>> datatype, which when cast through cstring was truncating python strings with
>> embedded nulls,
>> performance was only a secondary consideration
Heikki Linnakangas writes:
> Barring objections, I'm going to apply the indexam API changes part,
> since that simplifies the code in question regardless of the rest of the
> work. I'm pretty happy now with the indexfilter patch as well, but want
> to do some more testing on that before committing
Jean-Michel Pour? wrote:
-- Start of PGP signed section.
> Dear Friends,
>
> First, thank you very much for considering a fix on the GROUP BY issue.
> I am starting a new thread about another issue:
>
> It seems that DELETE cannot understand INNER JOINS and needs HAVING.
>
> Read:
> http://dru
I've been looking at bug #5000 (must be some kind of milestone), in
which the complaint was that the planner won't use an indexscan on a
functional index to satisfy an ORDER BY. Of course it *can* do that,
it's just not being very bright about it. Consider the following
example in the regression
Mark Cave-Ayland writes:
> So in conclusion, I think that patch looks good and that the extra time
> I was seeing was due to RECHECK being applied to the && operator, and
> not the time being spent within the index scan itself.
Thanks, I appreciate the followup.
I plan to go ahead and apply th
I didn't say that it _only_ affects bytea, I said that was the _primary
motivation_ for it.
Converting from postgres=>python this change affects boolean, float4, float8,
numeric, int16, int32, int64, text, and bytea. The code to handle this goes
through DatumGetXXX for the native C type for th
> The maintenance costs and update contention for such a datastructure
> would render this completely impractical, even if consulting it were
> free.
>
Thanks for the reply.
a) Only one transaction would be updating its commit status. Its multiple
readers Vs Single Writer for the position of a pa
On Fri, Aug 21, 2009 at 12:23:15PM +1000, Brendan Jurd wrote:
> 2009/8/21 Jeff Davis :
> > If they include indexes and not constraints, I think we should
> > follow the same policy as unique constraints, and create the index
> > and the constraint.
> >
> > The behavior seems a little strange to me,
Tom Lane wrote:
> It strikes me that in the cases where it wouldn't be necessary to
> compute junk sort-key columns, it would be because we were scanning an
> index that includes those values. So if the plan were set up to pull
> those values from the index and return them, then we'd not have to a
On Sat, Aug 22, 2009 at 12:39:41PM -0400, Tom Lane wrote:
> Mark Cave-Ayland writes:
> > So in conclusion, I think that patch looks good and that the extra time
> > I was seeing was due to RECHECK being applied to the && operator, and
> > not the time being spent within the index scan itself.
>
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Barring objections, I'm going to apply the indexam API changes part,
>> since that simplifies the code in question regardless of the rest of the
>> work. I'm pretty happy now with the indexfilter patch as well, but want
>> to do some more testing on
printTextLineFormat describes the characters used to draw vertical
lines across a horizontal rule at the left side, middle and right hand
side. These are included in the formatting for an entire table
(printTextFormat). The printTextRule enum is used as an offset into
the printTextFormat line rule
psql currently uses the ASCII characters '-' '|' and '+' to render
tables. However, most modern terminal emulators are capable of
displaying characters other than ASCII, including box drawing
characters which can be used to create rather more pleasing and
readable tables than ASCII punctuation can
print_aligned_text and print_aligned_vertical, and their
helper fuctions pass the table formatting and (where
applicable) line style information to allow correct
printing of table lines.
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c | 23 ++-
1 files changed, 14 inser
Convert print_aligned_text, and its helper function, to use
table formatting in place of hardcoded ASCII characters.
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c | 50 +-
1 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/src
Small followup patch to correct expanded=1 and border=0 output
as mentioned in previous email.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Pub
Convert print_aligned_vertical, and its helper function, to use
table formatting in place of hardcoded ASCII characters.
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c | 141 +++---
1 files changed, 87 insertions(+), 54 deletions(-)
diff --git a
Default to using the ASCII table. However, if a UTF-8
locale codeset is in use, switch to the UTF-8 table.
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 9d
Hi,
I just submitted a number of patches to this list, but due to
using my @debian.org address rather than the address used to
subscribe to the list, they appear to have got stuck!
Sorry for the noise, I don't know how often the moderated
mail queue is looked at, so thought it might be worth ment
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index e4e9f01..be81adc 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1014,7 +1014,7 @@ print_aligned_vertica
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index c6394ad..10faeb3 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1154,10 +1154,10 @@ print_aligned
Correct a corner case where the middle column separator overlaps
the right edge of the record number.
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index be81adc..c63
Further minor cleanups to tweak column alignment in a corner case,
and to correct indentation to match the rest of the code.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sou
Signed-off-by: Roger Leigh
---
src/bin/psql/print.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 7505cd4..9dec77d 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -356,6 +356,30 @@
On Sat, Aug 22, 2009 at 2:13 PM, Roger Leigh wrote:
> Further minor cleanups to tweak column alignment in a corner case,
> and to correct indentation to match the rest of the code.
Please read the guidelines here:
http://wiki.postgresql.org/wiki/Submitting_a_Patch
I don't think it's very helpful
On Sat, Aug 22, 2009 at 07:42:10PM -0400, Robert Haas wrote:
> On Sat, Aug 22, 2009 at 2:13 PM, Roger Leigh wrote:
> > Further minor cleanups to tweak column alignment in a corner case,
> > and to correct indentation to match the rest of the code.
>
> Please read the guidelines here:
> http://wiki
I posted a note about a week ago which drew far less commentary than I
expected, regarding the timetable for the release of 8.5.
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01256.php
Perhaps this is already being discussed on -core, but if so the
conclusions haven't been shared public
On Sun, Aug 23, 2009 at 1:49 AM, Roger Leigh wrote:
>> Please read the guidelines here:
>> http://wiki.postgresql.org/wiki/Submitting_a_Patch
>>
>> I don't think it's very helpful to submit a patch intended to do
>> basically one thing split up over 10 threads. The PostgreSQL style is
>> heavyweig
Greg Stark wrote:
I don't really have an opinion between one big patch versus multiple
smaller patches. That will come down to the code and whether the
separate patches are easier to read. It is sometimes hard to review a
patch when its separated from the code which needs the new
functionality
Like some ancient precursor to the modern hypot()enuse the dreaded
ill-tempered HYPOT()amus lurks in the recesses of geo_ops.c and
geo_decls.h. And many a line of code has been swallowed by its mighty maw.
This patch replaces the HYPOT() macro with a calls to the hypot() function.
The hypot() fu
On Sun, Aug 23, 2009 at 4:54 AM, Paul Matthews wrote:
>
> The hypot() function has been part of the C standard since C99 (ie 10
> years ago)
Postgres targets C89. The date of the standard is when the standard
came out, it takes years before it's widely available and then years
again before the sys
Greg Stark writes:
> If there's a performance advantage then we could add a configure test
> and define the macro to call hypot(). You said it existed before C99
> though, how widespread was it? If it's in all the platforms we support
> it might be reasonable to just go with it.
For one data poin
Robert Haas writes:
> I posted a note about a week ago which drew far less commentary than I
> expected, regarding the timetable for the release of 8.5.
> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01256.php
> Perhaps this is already being discussed on -core, but if so the
> conclus
41 matches
Mail list logo
