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
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),
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
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 below
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 th
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 c
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 ...
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
tha
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 the
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 o
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 requirement
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 y
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 a
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 i
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 - wind
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 to
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 keywor
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, ple
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 fo
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 w
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
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
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 b
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 í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 reg
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, th
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:
abc
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...)
Basical
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?
Or
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
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 --- mo
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 wo
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
> b
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
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 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 sup
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
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 com
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.sq
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
> > >
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 *print
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
>
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 re
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 03.1
44 matches
Mail list logo
