On Sun, 2005-12-04 at 12:49 -0300, Alvaro Herrera wrote:
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
On Sun, 2005-12-04 at 13:47 -0500, Pollard, Mike wrote:
Simon Riggs wrote
The system default is to have a prepared statement
bound to a plan on its first parameter bind.
We call it deferred optimization.
Do you really stop at the first parameter?
The first bind of parameters to the
On Mon, 2005-12-05 at 01:53 -0500, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
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 guarantee anyway.
But outlying data is something the user
On Dec 5, 2005, at 4:17 AM, Tom Lane wrote:
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
On Sun, Dec 04, 2005 at 10:40:55PM -0800, Kevin Brown wrote:
One thing I don't quite understand about the discussion is why there's
particular attention being paid to deadlocks with respect to REINDEX
when it clearly can happen in the general case when lock promotion is
involved. Why is
Ühel kenal päeval, R, 2005-12-02 kell 02:14, kirjutas Tom Lane:
Greg Stark [EMAIL PROTECTED] writes:
It was a *major* new feature that many people were waiting for when Oracle
finally implemented live CREATE INDEX and REINDEX. The ability to run create
an index without blocking any
I wrote:
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
Andrew Dunstan [EMAIL PROTECTED] writes:
However, a very simple test shows that the libintl printf does indeed do
%m$ processing:
...
So the next question is why isn't it working in the build.
Is it possible that the build that was being complained of was using our
previous, very-broken
Kevin Brown [EMAIL PROTECTED] writes:
And now I see why, since it will introduce deadlocks (sigh). But what
of the other rule (always acquiring locks against the table before the
index)? You may have stopped reading at the above...
We already do that.
One thing I don't quite understand
I wonder if it would work to release the AccessShareLock before
acquiring the ExclusiveLock. Of course, this would let any ALTER TABLE
or DROP TABLE to do anything they wanted, but we could check that the
table is still the same after reacquiring the exclusive lock. REINDEX
would have to abort
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, a very simple test shows that the libintl printf does indeed do
%m$ processing:
...
So the next question is why isn't it working in the build.
Is it possible that the build that was being complained of was using our
Andrew Dunstan [EMAIL PROTECTED] writes:
What is more, when I set the locale of my machine to Turkish and run the
installer project's 8.1_RC1 which I happen to have installed there, and
set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
LOG: $s veritaban?n
Tom Lane wrote:
The concern about deadlock applies to the various proposals that involve
upgrading to a write-prevention lock at some late point in the process.
That clearly has the potential to deadlock against relatively weak lock
requests.
After looking at the various lock types, I don't
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
What is more, when I set the locale of my machine to Turkish and run the
installer project's 8.1_RC1 which I happen to have installed there, and
set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
LOG: $s
Andrew Dunstan [EMAIL PROTECTED] writes:
With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
made yesterday, I see the result above, i.e. what we expect from our own
breakage of sprintf (i haven't yet updated the snapshot I took).
Ah. OK, that makes sense.
But the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
made yesterday, I see the result above, i.e. what we expect from our own
breakage of sprintf (i haven't yet updated the snapshot I took).
Ah. OK, that
Hans-Juergen Schoenig [EMAIL PROTECTED] writes:
I think I know what Greg is trying to say: I think in this plan stability
does not mean that the plan has to be completely fixed - usually it is all
about indexing.
Usually problems occur because someone hasn't run analyze at all. That's not
[snip]
I want to be sure my existing queries keep using the plans they've been using
until I allow them to change.
I don't want to sit down and type select count(*) from users and have it not
work correctly (ie, use a sequential scan) because the system is so single
mindedly tuned for the
Jan Wieck írta:
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
[ Moved to hackers for patch discussion.]
John D. Burger wrote:
There are practical applications, eg, 1024-bit keys are fairly common
objects in cryptography these days, and that equates to about 10^308.
I don't really foresee anyone trying to run crypto algorithms with SQL
NUMERIC
Bruce Momjian wrote:
Was the last patch you sent in ready for application, or are you still
fooling with it?
He is still working on it. It did not handle all *printf functions, as
he mentioned, and he might have other changes.
Yeah.
The good news: the new pg_*printf does the
On 12/5/2005 1:03 PM, Zoltan Boszormenyi wrote:
Jan Wieck írta:
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. ...
Andrew Dunstan [EMAIL PROTECTED] writes:
The bad news: if we aren't compiling with NLS enabled, having those
entries in exports.txt makes the libpq build blow up. So either we need
to use pg_*printf unconditionally on Windows, or we need a little
Makefile + sed magic to strip those entries
Andrew Dunstan [EMAIL PROTECTED] writes:
With luck I can probably wrap this up today for the 8.1 stable branch -
it would be nice if the new release actually did NLS right.
BTW, core has already agreed to postpone the releases a couple days
while we make sure we have this problem nailed down.
Bruce Momjian pgman@candle.pha.pa.us writes:
The limit seems to be around 150k digits:
It's exactly 10^(128K), as I've mentioned more than once.
So, with the patch, the storage length is going from 1000 digits to 508,
but the computational length is reduced from around 150k digits to 508.
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The bad news: if we aren't compiling with NLS enabled, having those
entries in exports.txt makes the libpq build blow up. So either we need
to use pg_*printf unconditionally on Windows, or we need a little
Makefile + sed magic to
On 12/5/05, Tom Lane [EMAIL PROTECTED] wrote:
Not only does 4000! not work, but 400! doesn't even work. I just lost
demo wow factor points!
It looks like the limit would be about factorial(256).
The question remains, though, is this computational range good for
anything except demos?
-Original Message-
From: Andrew Dunstan[EMAIL PROTECTED]
Sent: 05/12/05 19:03:17
To: Tom Lane[EMAIL PROTECTED]
Cc: Bruce Momjianpgman@candle.pha.pa.us, [EMAIL PROTECTED][EMAIL
PROTECTED], [EMAIL PROTECTED][EMAIL PROTECTED], [EMAIL PROTECTED][EMAIL
PROTECTED],
Jan Wieck írta:
On 12/5/2005 1:03 PM, Zoltan Boszormenyi wrote:
Jan Wieck írta:
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
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
What about Plan B? Per Bruce's comment, it should really only be ecpg
that needs an extra copy of snprintf.o, and it's not like ecpg doesn't
already pull in various port/ files for itself.
The problem is that the alias will be picked
What about replication or data distribution inside the backend. This is a valid issue?
Thanks,
Gustavo.
I wrote:
The way the attached patch attacks this is for the shared-lock access
case to simply set the page's LRU counter to zero, without bumping up
the LRU counters of the other pages as the normal adjustment would do.
...
I'm not totally happy with this heuristic, though, and was
wondering
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The problem is that the alias will be picked up by every libpq client.
Not at all; libpq clients do not import c.h.
Well, all the programs that use postgres-fe.h do.
Sure, but all of them do
Tom, did you implement this functionality in *printf?
The size may be given as zero to find out how many characters are
needed; in this case, the str argument is ignored. Sprintf() and
vsprintf() effectively assume an infinite size.
Looking at the code it doesn't seem
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom, did you implement this functionality in *printf?
The size may be given as zero to find out how many characters are
needed; in this case, the str argument is ignored. Sprintf() and
vsprintf() effectively assume an infinite
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom, did you implement this functionality in *printf?
The size may be given as zero to find out how many characters are
needed; in this case, the str argument is ignored. Sprintf() and
vsprintf() effectively assume
Bruce Momjian pgman@candle.pha.pa.us writes:
Upon successful completion snprintf() and vsnprintf() return the number
of characters that would have been written to a sufficiently sized str,
excluding the terminating NUL character.
but it seems this is some BSD'ism that we
To reduce size of varlen2.vl_len to int16. This has been mentioned before,
but is there any show-stopper reasoning preventing us from doing that or
somebody has been working on it?
Sorry, just to repeat myself. Char types will benefit from that. Many
applications are from DB2, Oracle or SQL
On Mon, Dec 05, 2005 at 04:35:31PM -0500, Bruce Momjian wrote:
but it seems this is some BSD'ism that we don't need to support if the
standard doesn't say so.
I think the Linux manpage is more informative about this:
The functions snprintf and vsnprintf do not write more than
Qingqing Zhou [EMAIL PROTECTED] writes:
To reduce size of varlen2.vl_len to int16. This has been mentioned before,
but is there any show-stopper reasoning preventing us from doing that or
somebody has been working on it?
Sorry, just to repeat myself. Char types will benefit from that.
I have
Tom Lane wrote:
I'm coming around to thinking that the simple solution is just to use it
unconditionally on Windows.
I agree that that's what we should do, but it should be done the same
way we handle other routines from libpgport. None of those are exported
to our client-side
Andrew Dunstan wrote:
Tom Lane wrote:
I'm coming around to thinking that the simple solution is just to
use it unconditionally on Windows.
I agree that that's what we should do, but it should be done the same
way we handle other routines from libpgport. None of those are exported
Qingqing Zhou [EMAIL PROTECTED] wrote:
To reduce size of varlen2.vl_len to int16. This has been mentioned before,
but is there any show-stopper reasoning preventing us from doing that or
somebody has been working on it?
Hi, I'm rewriting the patch that I proposed before.
Gustavo Tonini wrote:
replication (master/slave, multi-master, etc) implemented inside
postgres...I would like to know what has been make in this area.
http://www.commandprompt.com/ - Master/Slave
Joshua D. Drake
Gustavo.
P.S. Sorry for my bad English.
2005/12/5, Chris Browne [EMAIL
replication (master/slave, multi-master, etc) implemented inside
postgres...I would like to know what has been make in this area.
It's not in the backend, check out things like Slony (www.slony.info)
and various other commercial solutions.
Chris
---(end of
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, eyeball this for the REL8_1_STABLE branch, please. It seems to
work for me. No exports necessary.
er try this instead. I missed a line from configure.in
I cleaned this up slightly and committed it into HEAD and 8.1 branches.
It appears to work in
Hi,
Playing around with this MySQL compatibility library, I noticed that
pg_dump -c does not emit DROP commands for casts. Seems like a bug...?
Chris
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, eyeball this for the REL8_1_STABLE branch, please. It seems to
work for me. No exports necessary.
er try this instead. I missed a line from configure.in
I cleaned this up slightly and committed it into HEAD
I did some research and can report what was happening with *printf and
libintl.
Basically, there are two versions of libintl. Versions before 0.13
(November 2003) use the libc version of *printf to handle printing of
translation strings. Version 0.13 and after provide their own *printf
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
The limit seems to be around 150k digits:
It's exactly 10^(128K), as I've mentioned more than once.
So, with the patch, the storage length is going from 1000 digits to 508,
but the computational length is reduced from around
Andrew Dunstan [EMAIL PROTECTED] writes:
Also, we need a way to stop this from happening all over the build:
In file included from ../../../../../../src/include/c.h:820,
from ../../../../../../src/include/postgres.h:48,
from utf8_and_sjis.c:14:
Tom Lane wrote:
Not sure why my build didn't show the problem in pgtypeslib, though.
That should have failed with or without libintl macros.
On *nix it probably just thinks it's an external symbol to be resolved
later.
cheers
andrew
---(end of
Andrew Dunstan [EMAIL PROTECTED] writes:
If we don't do this then we need to link snprintf into libpgtypes just
like we do for ecpg, but it seems like overkill.
It might be overkill today, but what about tomorrow when someone decides
to internationalize libpgtypes? I made it link in there
On 12/5/2005 8:18 PM, Gustavo Tonini wrote:
replication (master/slave, multi-master, etc) implemented inside
postgres...I would like to know what has been make in this area.
We do not plan to implement replication inside the backend. Replication
needs are so diverse that pluggable
On Mon, Dec 05, 2005 at 11:59:10PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
It looks like the limit would be about factorial(256).
The question remains, though, is this computational range good for
anything except demos?
I can say that the extended range is good for finding *printf
Michael Fuhr [EMAIL PROTECTED] writes:
On Mon, Dec 05, 2005 at 11:59:10PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
The question remains, though, is this computational range good for
anything except demos?
I can say that the extended range is good for finding *printf problems. ;-)
OK, I give up - how do I convert an INET type to a NUMERIC
representation of its network address?
Is there a quick and easy way?
Chris
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Tue, Dec 06, 2005 at 03:31:59PM +0800, Christopher Kings-Lynne wrote:
OK, I give up - how do I convert an INET type to a NUMERIC
representation of its network address?
How about:
CREATE FUNCTION inet2num(inet) RETURNS numeric AS $$
use Socket;
return unpack(N, inet_aton($_[0]));
$$
On 12/6/05, Michael Fuhr [EMAIL PROTECTED] wrote:
How about:CREATE FUNCTION inet2num(inet) RETURNS numeric AS $$use Socket;return unpack(N, inet_aton($_[0]));$$ LANGUAGE plperlu IMMUTABLE STRICT;
you can use this one:
... AS $$
return unpack(N, pack(C4, split(/\./, $_[0])));
$$ language plperl
PL/SQL or PL/PGSQL...
Chris
Michael Fuhr wrote:
On Tue, Dec 06, 2005 at 03:31:59PM +0800, Christopher Kings-Lynne wrote:
OK, I give up - how do I convert an INET type to a NUMERIC
representation of its network address?
How about:
CREATE FUNCTION inet2num(inet) RETURNS numeric AS $$
use
60 matches
Mail list logo
