Title: AW: [HACKERS] Strange left join problems in 8.1
I've tried this with cvs , -r REL8_1_STABLE (hope this was the right one), and works flawless now.
Thanks a lot!
Best regards
Mario Weilguni
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:[EMAIL PROTECTED]]
Gesendet: Sa
On Fri, 2005-12-02 at 11:07 +0100, Csaba Nagy wrote:
On Thu, 2005-12-01 at 22:01, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
On the other hand the type I would prefer to see are hints that feed
directly
into filling in information the planner lacks. This only requires that
Simon Riggs wrote:
ISTM we could do some of that with another GUC, lets call it
prepare_once = on. The system default is to have a prepared statement
bound to a plan on its first parameter bind. If we set this to off,
then the statement will replan each time we bind. This would give us
both
Bruce Momjian wrote:
OK, here is what happened. In March 2005, we got reports of compile
problems on Win32 using NLS:
http://archives.postgresql.org/pgsql-hackers/2005-03/msg00710.php
(See the quoted text under the posted text as well.) Basically,
libintl.h on Win32 replaces
On Sat, Dec 03, 2005 at 10:54:08AM -0500, Bruce Momjian wrote:
Neil Conway wrote:
On Wed, 2005-11-30 at 10:56 -0500, Tom Lane wrote:
It's been about a month since 8.1.0 was released, and we've found about
the usual number of bugs for a new release, so it seems like it's time
for 8.1.1.
Paul Lindner [EMAIL PROTECTED] writes:
To convert your pre-8.1 database to 8.1 you may have to remove and/or
fix the offending characters. One simple way to fix the problem is to
run your pg_dump output through the iconv command like this:
iconv -c -f UTF8 -t UTF8 -o fixed.sql dump.sql
Is
On Sun, Dec 04, 2005 at 11:34:16AM -0500, Tom Lane wrote:
Paul Lindner [EMAIL PROTECTED] writes:
To convert your pre-8.1 database to 8.1 you may have to remove and/or
fix the offending characters. One simple way to fix the problem is to
run your pg_dump output through the iconv command
Paul Lindner [EMAIL PROTECTED] writes:
On Sun, Dec 04, 2005 at 11:34:16AM -0500, Tom Lane wrote:
Paul Lindner [EMAIL PROTECTED] writes:
iconv -c -f UTF8 -t UTF8 -o fixed.sql dump.sql
Is that really a one-size-fits-all solution? Especially with -c?
I'd say yes, and the -c flag is needed so
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
Even ignoring that, you *still* have a lock upgrade problem
in this sketch.
Hmm, well, I can see a deadlock potential for those operations that
have to acquire multiple locks simultaneously, and I suppose that the
On 12/4/05, Tom Lane [EMAIL PROTECTED] wrote:
Paul Lindner [EMAIL PROTECTED] writes:
On Sun, Dec 04, 2005 at 11:34:16AM -0500, Tom Lane wrote:
Paul Lindner [EMAIL PROTECTED] writes:
iconv -c -f UTF8 -t UTF8 -o fixed.sql dump.sql
Is that really a one-size-fits-all solution? Especially
Kevin Brown [EMAIL PROTECTED] writes:
I guess the real question here is: is it possible to, in code,
guarantee the order of lock acquisition by any given transaction?
Yes, but not in our code :-(. This is largely determined by what the
application does.
regards, tom
Simon Riggs wrote
ISTM we could do some of that with another GUC, lets call it
prepare_once = on. The system default is to have a prepared statement
bound to a plan on its first parameter bind. If we set this to off,
then the statement will replan each time we bind. This would give us
both
Andrew Dunstan wrote:
Tom said:
Would it work to modify c.h so that it #include's libintl.h, then
#undefs
these macros, then #includes port.h to define 'em the way we want?
Some or all of this might need to be #ifdef WIN32, but that seems like
a reasonably noninvasive solution if it can
On Sun, Dec 04, 2005 at 12:19:32PM -0500, Gregory Maxwell wrote:
That's exactly what's bothering me about it. If we recommend that
we had better put a large THIS WILL DESTROY YOUR DATA warning first.
The problem is that the data is not invalid from the user's point
of view --- more
Andrew Dunstan [EMAIL PROTECTED] writes:
That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that - windows
experts, please advise.
Plan A would be to
Tom Lane wrote:
While Win32 supports 64-bit files, the MinGW API does not,
meaning we have to build an fseeko replacement on top of the
Win32 API, and we have to make sure MinGW handles it.
Wouldn't it be better to lobby the MinGW folk to fix their problem?
Hi,
I believe I've found a performance regression between 8.0 and 8.1 for
some cases. For some queries it appears that the old MIN() ran much
faster than the new optimized MIN().
The following set of query plans illustrates the problem. (schema
names changed to protect the innocent...)
I started to do some simple testing of snprintf.c after doing the
cleanup work I had in mind, and soon found that neither my version
nor the original actually do parameter reordering correctly:
$ ./testf 'abc%2$sfoo%1$s' DEF GHI
sys:
abcGHIfooDEF--- looks right to me
ours:
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I guess the real question here is: is it possible to, in code,
guarantee the order of lock acquisition by any given transaction?
Yes, but not in our code :-(. This is largely determined by what the
application does.
Yeah, that's what
Andrew Dunstan írta:
Zoltan Boszormenyi wrote:
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
I can't see this item on the TODO list at all. Where exactly did you
find it?
That's why I wanted it ADDed... ;-)
Best
Peter Eisentraut írta:
Josh Berkus wrote:
I believe that our SERIAL/SEQUENCE stuff is already in compliance
with the SQL standard for sequences (in SQL03). Why would we change
it?
Because your belief is wrong, but Zoltan's proposal is not getting is
closer.
OK, what does the
Andrew Dunstan wrote:
Tom Lane wrote:
While Win32 supports 64-bit files, the MinGW API does not,
meaning we have to build an fseeko replacement on top of the
Win32 API, and we have to make sure MinGW handles it.
Wouldn't it be better to lobby the
Bruce Momjian wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
While Win32 supports 64-bit files, the MinGW API does not,
meaning we have to build an fseeko replacement on top of the
Win32 API, and we have to make sure MinGW handles it.
Wouldn't it
Zoltan Boszormenyi wrote:
Peter Eisentraut ?rta:
Josh Berkus wrote:
I believe that our SERIAL/SEQUENCE stuff is already in compliance
with the SQL standard for sequences (in SQL03). Why would we change
it?
Because your belief is wrong, but Zoltan's proposal is not getting
Zoltan Boszormenyi wrote:
Andrew Dunstan írta:
Zoltan Boszormenyi wrote:
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
I can't see this item on the TODO list at all. Where exactly did you
find it?
That's why I
OK, I admit I haven't read the SQL standards on this matter.
Tino Wildenhain írta:
Am Samstag, den 03.12.2005, 22:23 +0100 schrieb Zoltan Boszormenyi:
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
To achieve this, the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that - windows
experts, please
Am Sonntag, den 04.12.2005, 08:52 +0100 schrieb Zoltan Boszormenyi:
OK, I admit I haven't read the SQL standards on this matter.
Tino Wildenhain írta:
...
A SERIAL type has the assumption that its value starts at a low value
(1) and
is increasing. Or is there a type modifier keyword that
Jan Wieck írta:
On 12/3/2005 4:23 PM, Zoltan Boszormenyi wrote:
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
To achieve this, the following three requirements should be fulfilled:
1. The statement parser should be able
Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that -
Zoltan Boszormenyi wrote:
I found this in the SQL2003 draft:
4.14.7 Identity columns
... An identity column has a start value, an increment, a maximum
value, a minimum value,
and a cycle option. ...
And that section says nothing at all about using 0 as a magic value. All
it says
On 12/4/2005 5:10 PM, Zoltan Boszormenyi wrote:
I found this in the SQL2003 draft:
4.14.7 Identity columns
... An identity column has a start value, an increment, a maximum value,
a minimum value,
and a cycle option. ...
The exact properties of a sequence. It would be a good idea to be
On Dec 5, 2005, at 9:50 , Jan Wieck wrote:
If we had to pick any magic value I would vote for skipping 666 in
all sequence generators and use that.
What about 13?
Michael Glaesemann
grzm myrealbox com
---(end of broadcast)---
TIP 3: Have
Simon Riggs [EMAIL PROTECTED] writes:
Csaba raises a good point here. Many people say they want hints when
what they actually require the plan to be both stable and predictable.
Plan stability is also an important feature, especially for OLTP systems which
have hard real-time requirements.
Kevin Brown [EMAIL PROTECTED] writes:
The fact that you've been holding the AccessShareLock for quite a
long time means that the window for deadlock problems is very wide.
But with respect to deadlocks, that's true only if deadlocks are
possible, which is true only if the order of lock
I think nobody would object to implementing support for the SQL2003
syntax. Most of that would be providing all the values that will get
forwarded into the internal sequence generation during CREATE TABLE.
Someone also pointed out on IRC the other day that Oracle and DB2 list
'identity' as
Paul Lindner [EMAIL PROTECTED] writes:
I believe I've found a performance regression between 8.0 and 8.1 for
some cases. For some queries it appears that the old MIN() ran much
faster than the new optimized MIN().
When you are complaining about planner mistakes, showing EXPLAIN rather
than
Kevin Brown [EMAIL PROTECTED] writes:
- when requesting a type of lock, one must first acquire all lesser
lock types against the object in order of strength. Hence, one must
acquire AccessShareLock before acquiring AccessExclusiveLock.
This is exactly wrong ...
Greg Stark [EMAIL PROTECTED] writes:
Plan stability is also an important feature, especially for OLTP
systems which have hard real-time requirements. OLTP systems typically
don't care about getting the best plan for a query, only a plan that
is good enough.
Good enough means it can keep up
Hi all,
On Sun, 4 Dec 2005, Tom Lane wrote:
Paul Lindner [EMAIL PROTECTED] writes:
To convert your pre-8.1 database to 8.1 you may have to remove and/or
fix the offending characters. One simple way to fix the problem is to
run your pg_dump output through the iconv command like this:
OK, a few things. First, Tom has fixed snprintf.c so it should properly
process positional parameters now. Would you first test the libintl
version of *printf to see if it can process %$ parameters (probably by
hacking up any language file and testing the printing), and then try
your patch
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
- when requesting a type of lock, one must first acquire all lesser
lock types against the object in order of strength. Hence, one must
acquire AccessShareLock before acquiring AccessExclusiveLock.
This is exactly wrong ...
And
Bruce Momjian said:
OK, a few things. First, Tom has fixed snprintf.c so it should
properly process positional parameters now. Would you first test the
libintl version of *printf to see if it can process %$ parameters
(probably by hacking up any language file and testing the printing),
and
Tom Lane [EMAIL PROTECTED] writes:
Is it worth pointing out that using the same plan all the time is *no*
recipe for guaranteeing response time? There is no such thing as a plan
that is good for every case --- outlying data values can make a
usually-good plan blow out your performance
44 matches
Mail list logo
