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
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?
snip
Does
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,
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
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
On Sat, Aug 22, 2009 at 11:45 AM, Caleb Weltoncwel...@greenplum.com 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
Gokulakannan Somasundaram gokul...@gmail.com 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
Zdenek Kotala zdenek.kot...@sun.com 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
Greg Stark gsst...@mit.edu writes:
On Sat, Aug 22, 2009 at 11:45 AM, Caleb Weltoncwel...@greenplum.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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:
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 mark.cave-ayl...@siriusit.co.uk 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
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
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
On Fri, Aug 21, 2009 at 12:23:15PM +1000, Brendan Jurd wrote:
2009/8/21 Jeff Davis pg...@j-davis.com:
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
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 add
On Sat, Aug 22, 2009 at 12:39:41PM -0400, Tom Lane wrote:
Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk 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
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
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
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 rle...@debian.org
---
src/bin/psql/print.c | 23 ++-
1 files
Convert print_aligned_text, and its helper function, to use
table formatting in place of hardcoded ASCII characters.
Signed-off-by: Roger Leigh rle...@debian.org
---
src/bin/psql/print.c | 50 +-
1 files changed, 37 insertions(+), 13 deletions(-)
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
Convert print_aligned_vertical, and its helper function, to use
table formatting in place of hardcoded ASCII characters.
Signed-off-by: Roger Leigh rle...@debian.org
---
src/bin/psql/print.c | 141 +++---
1 files changed, 87 insertions(+), 54
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 rle...@debian.org
---
src/bin/psql/print.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/bin/psql/print.c
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
Signed-off-by: Roger Leigh rle...@debian.org
---
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 @@
Signed-off-by: Roger Leigh rle...@debian.org
---
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
Correct a corner case where the middle column separator overlaps
the right edge of the record number.
Signed-off-by: Roger Leigh rle...@debian.org
---
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
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?
Signed-off-by: Roger Leigh rle...@debian.org
---
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
@@
On Sat, Aug 22, 2009 at 2:13 PM, Roger Leighrle...@debian.org 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
On Sat, Aug 22, 2009 at 07:42:10PM -0400, Robert Haas wrote:
On Sat, Aug 22, 2009 at 2:13 PM, Roger Leighrle...@debian.org 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:
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
On Sun, Aug 23, 2009 at 1:49 AM, Roger Leighrle...@codelibre.net 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
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()
On Sun, Aug 23, 2009 at 4:54 AM, Paul Matthewsp...@netspace.net.au 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
Greg Stark gsst...@mit.edu 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
40 matches
Mail list logo
