On Mon, 2003-11-03 at 04:21, Hannu Krosing wrote:
Neil Conway kirjutas E, 03.11.2003 kell 08:07:
(2) ISTM that we can set POSIX_FADV_RANDOM for *all* indexes, since the
vast majority of the accesses to them shouldn't be sequential.
Perhaps we could do it for all _leaf_ nodes, the root
On Mon, 2003-11-03 at 10:01, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
POSIX_FADV_RANDOM doesn't effect the page cache, it just determines how
aggressive the kernel is when doing readahead (at least on Linux, but
I'd expect to see other kernels implement similar behavior).
I
On Mon, 2003-11-03 at 11:11, Tom Lane wrote:
Why not? The advice says that you're going to access the data
sequentially in the forward direction. If you're not going to back up,
there is no point in keeping pages in cache after they've been read.
The advice says: I'm going to read this data
On Mon, 2003-11-03 at 12:17, Hannu Krosing wrote:
Can you use combinations like ( FADV_NOREUS | FADV_SEQUENTIAL )
You can do an fadvise() for FADV_SEQUENTIAL, and then another fadvise()
for FADV_NOREUSE.
-Neil
---(end of broadcast)---
TIP 4:
On Mon, 2003-11-03 at 09:38, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Given a Relation and an advice, this would:
(a) propagate the advice for this relation to all the open FDs for the
relation
All? You cannot affect the FDs being used by other backends.
Sorry, I meant
On Mon, 2003-11-03 at 14:24, Manfred Spraul wrote:
Neil: what about calling posix_fadvise for the whole file immediately
after issue_xlog_fsync() in XLogWrite? According to the comment, it's
guaranteed that this will happen only once.
Or: add an posix_fadvise into issue_xlog_fsync(), for
In the BufferDesc struct, there seem to be two ways to mark a buffer
page as dirty: setting the BM_DIRTY bit mask in the 'flags' field of the
struct, and setting the 'cntxDirty' field to true. What is the
difference between these two indications of a page's dirtiness?
Or, more to the point, is
Jan Wieck [EMAIL PROTECTED] writes:
This patch contains the still not yet ready performance improvements
discussed over the couple last days.
Cool stuff!
The buffer replacement strategy is a slightly modified version of
ARC.
BTW Jan, I got your message about taking a look at the ARC code;
Josh Berkus [EMAIL PROTECTED] writes:
Oh, and how about we kill the Image Map of major developers? It's about 4
years out of date, and makes developers.postgresql.org load like molasses in
January.
Personally, I don't really see the need for developer.postgresql.org
to be a separate
Bruce Momjian [EMAIL PROTECTED] writes:
Now, the disadvantages of large kernel cache, small PostgreSQL buffer
cache is that data has to be transfered to/from the kernel buffers, and
second, we can't control the kernel's cache replacement strategy, and
will probably not be able to in the near
Larry Rosenman [EMAIL PROTECTED] writes:
You might also look at Veritas' advisory stuff.
Thanks for the suggestion -- it looks like we can make use of
this. For the curious, the cache advisory API is documented here:
http://www.lerctr.org:8458/en/man/html.7/vxfsio.7.html
[EMAIL PROTECTED] writes:
I am trying to catch the UPDATE 0 condition in postgresql.
I have tried it using triggers, but they are only fired when there
effectively is an update.
You could try using an AFTER STATEMENT trigger (which will be invoked
even if zero rows are updated), and checking
Bruce Momjian [EMAIL PROTECTED] writes:
Another idea --- if fsync() is slow because it can't find the dirty
buffers, use write() to write the buffers, copy the buffer to local
memory, mark it as clean, then open the file with O_SYNC and write
it again.
Yuck.
Do we have any idea how many
Jan Wieck [EMAIL PROTECTED] writes:
We can't resize shared memory because we allocate the whole thing in
one big hump - which causes the shmmax problem BTW. If we allocate
that in chunks of multiple blocks, we only have to give it a total
maximum size to get the hash tables and other stuff
Bruce Momjian [EMAIL PROTECTED] writes:
Is there a TODO here?
You needn't add one: I hope to tackle this during the 7.5 dev cycle.
-Neil
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
bpalmer [EMAIL PROTECTED] writes:
I'm trying to figure out what version of a source code I have. I know
it's a 7.2 release, but how can I find out of it's 7.2, 7.2.3, 7.2.4,
etc. FROM THE SOURCE CODE, not from compiling (it doesn't compile, it's
testing code).
Look in configure.in:
Hannu Krosing [EMAIL PROTECTED] writes:
For me, the start of transaction is not about time, but about grouping
a set of statements into one. So making the exact moment of start be
the first statement that actually does something with data seems
perfectly reasonable.
This might be a perfectly
Tom Lane [EMAIL PROTECTED] writes:
That's defensible when the user issued the BEGIN himself. When the
BEGIN is coming from some interface library's autocommit logic, it's
a lot less defensible. If you consult the archives, you will find
actual user complaints about why is now() returning a
I'd like to add a new column to pg_attribute that specifies the
attribute's logical position within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows us to easily
quickly change column order,
I'd like to add a new column to pg_attribute that specifies the
attribute's logical position within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows us to easily
quickly change column order,
Peter Eisentraut [EMAIL PROTECTED] writes:
I don't think you can speak of bloat for pg_attribute. But you
can speak of a problem when you want to do the old col = col + 1 in
the presence of a unique index.
I'm sorry, but I'm not sure what either of these comments mean -- can
you elaborate?
Jon Jensen [EMAIL PROTECTED] writes:
You're just saying it'd break old dumps, right? I'd assume COPY FROM
would use attpos ordering when writing out columns, or that every
user-visible interaction with the table pretends the columns are in
attpos order. So dumps would break no more or less
Josh Berkus [EMAIL PROTECTED] writes:
It seems certain that the next release, in 6-9 months, will have at
a minimum the Windows port and ARC, if not Slony-I as well.
Given all that, don't people think it's time to jump to 8.0?
It seems a little premature to speculate on what features may or
Peter Eisentraut [EMAIL PROTECTED] writes:
The time from release 7.3 to release 7.4 was 355 days, an all-time
high. We really need to shorten that.
Why is that?
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
Peter Eisentraut [EMAIL PROTECTED] writes:
First, if you develop something today, the first time users would
realistically get a hand at it would be January 2005. Do you want
that? Don't you want people to use your code?
Sure :-) But I don't mind a long release cycle if it is better for
Matthew T. O'Connor [EMAIL PROTECTED] writes:
So 7.4 took about 4.5 months to get from feature freeze to release.
I think feature freeze is the important date that developers of new
features need to concern themselves with.
Rather than the length of the release cycle, I think it's the length
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
0. As you say, make it known to the public. Have people test their
in-development applications using a beta.
and how do you propose we do that? I think this is the hard part
(1) Make the beta more
Tom Lane [EMAIL PROTECTED] writes:
attpos is a horrid choice of name, because no one will be able to
remember which of attnum and attpos is which. Pick a more
distinct name. Offhand the best thing I can think of is attlognum
or attlogpos.
Actually, I deliberately chose attpos rather than
I noticed the following code in src/backend/rewrite/rewriteDefine.c,
circa line 390:
/*
* Are we converting a relation to a view?
*
* If so, check that the relation is empty because the storage
* for the relation
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is there demand for this syntax:
ALTER SEQUENCE ON table(col) CYCLE 100;
What if the values in a column are generated via a sequence that was
created independently -- i.e. it's not a SERIAL column?
I'm not very enthusiastic about features that
With a recent snapshot of CVS HEAD:
make[1]: Leaving directory `/home/nconway/build-pgsql-cvs/src/backend/parser'
gcc -O0 -g -Wall -Wmissing-prototypes -Wmissing-declarations
-I/home/nconway/pgsql/src/interfaces/libpq -I../../../src/include
-I/home/nconway/pgsql/src/include -D_GNU_SOURCE
GCC supports the -Wshadow command-line option:
-Wshadow
Warn whenever a local variable shadows another local
variable, parameter or global variable or whenever a
built-in function is shadowed.
Currently, enabling this for the PostgreSQL tree produces a lot
Tom Lane [EMAIL PROTECTED] writes:
Neil Conway [EMAIL PROTECTED] writes:
Currently, enabling this for the PostgreSQL tree produces a lot of
warnings.
How many is a lot?
Maybe a couple hundred or so, but most of the warnings are derived
from a few globals with common names -- I would guess
Tom Lane [EMAIL PROTECTED] writes:
I wouldn't object to something that catches shadowings of parameters
or local variables, but I think the flag as defined is not very
useful.
On closer examination, that seems like a prescient comment. There are
about 1100 distinct warnings enabled by this
Robert Treat [EMAIL PROTECTED] writes:
Seems merging the two would work... attlogpos, the attributes
logical position.
Unless anyone has any further objections, I'll switch to using attlogpos.
-Neil
---(end of broadcast)---
TIP 2: you can get
Tom Lane [EMAIL PROTECTED] writes:
This is a backwards-compatibility hangover.
But I'd not want to break it just because someone thinks the hack is
ugly. It was ugly from day one.
I agree it shouldn't be removed -- I was just curious to see what was
using it. It's certainly ugly, though.
Dennis Bjorklund [EMAIL PROTECTED] writes:
It's strange to allow identifiers to be of any length in the system
table when there is no way to create it using normal syntax.
I agree with Tom -- that doesn't seem strange to me at all.
-Neil
---(end of
Tom Lane [EMAIL PROTECTED] writes:
I think such a thing would have such a low signal-to-noise ratio as
to be useless :-(. As you note, there are many places where the
planner's estimate is routinely off by more than 3x (or any other
threshold you might pick instead).
I wonder, perhaps we
Building PostgreSQL outside the source tree is slightly broken:
(Using the current CVS HEAD code)
$ mkdir ~/test-pg-build
$ cd ~/test-pg-build
$ ../pgsql/configure
[ output omitted]
$ make
[ output omitted; make succeeds ]
$ touch ../pgsql/configure # i.e. cvs up
$ make
The final make
Greg Stark [EMAIL PROTECTED] writes:
There's a dual to this as well. If the results were very close but
the actual time taken to run the node doesn't match the cost
calculated then some optimizer parameter needs to be adjusted.
I was thinking about this, but I couldn't think of how to get it
Greg Stark [EMAIL PROTECTED] writes:
At least for all the possible plans of a given query at a specific
point in time the intention is that the cost be proportional to the
execution time.
Why is this relevant?
Given a cost X at a given point in time, the system needs to derive an
expected
Tom Lane [EMAIL PROTECTED] writes:
Whoa. Try the following test program.
I tried this on two uniprocessor x86 machines:
(1)
$ uname -a
Linux tokyo 2.6.0-test10 #3 Mon Nov 24 13:43:54 EST 2003 i686 GNU/Linux
This machine produces this output, after running the test app for
about 30 minutes:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 28 Nov 2003, Neil Conway wrote:
$ uname -a
FreeBSD home.samurai.com 4.9-RELEASE [...]
what is kern.timecounter.method set to?
$ sysctl kern.timecounter.method
kern.timecounter.method: 0
FYI, I ran the test program for another 30 minutes
Marc G. Fournier [EMAIL PROTECTED] writes:
What kinda processor are you running?
From dmesg:
Timecounter i8254 frequency 1193182 Hz
CPU: Intel Celeron (631.29-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
Tom Lane [EMAIL PROTECTED] writes:
I believe the idea is that instead of
--with-krb5=/usr/kerberos
you now need
--with-krb5 --with-includes=/usr/kerberos/include \
--with-libs=/usr/kerberos/lib
Rather than silenty accepting but ignoring the old syntax, could we
have configure bail out
Jonathan Gardner [EMAIL PROTECTED] writes:
3) We would implement some sort of differential view update scheme
based on the paper Efficiently Updating Materialized Views[1].
One resource on this topic that appears to be quite authoritative is
Materialized Views: Techniques, Implementations,
Oliver Elphick [EMAIL PROTECTED] writes:
The use of the word log in the directory name does tend to invite
this error, and some have acted on it without asking first. I think
initdb should put a README.IMPORTANT file in $PGDATA to say [...]
If someone deletes something from $PGDATA without
Marc G. Fournier [EMAIL PROTECTED] writes:
To accomodate ppls travel scheduales, we are going to move the 7.4.1
release up to Monday, *unless* there is a report before then about
something that needs to be fixed first
The libpq SSL memory leak reported on -bugs would be good to fix.
BTW, is
I recently had the opportunity to take an upper-year/graduate-level
course on DBMS internals at my university. While taking that course, I
wrote some notes on course material as a study aid. I thought that
perhaps some of the people on -hackers might find the notes somewhat
useful, so Bruce was
[EMAIL PROTECTED] writes:
Is there ay way I can help with this debugging?
Can you speculate on what might have caused the crash?
Is the crash reproducible?
When the backend crashed, it should have produced a core file
(assuming your system is configured to do so). Can you post the
stacktrace
Andrew Dunstan [EMAIL PROTECTED] writes:
Frank Wiles wrote:
Not to mention it would kill PostgreSQL's current speedy
performance!
Maybe, maybe not. Modern JVMs have much better performance
characteristics than was once the case. Also, some of the things
that Java buys you (memory
We reject the following query:
nconway=# create table abc (a int, b int, c int);
CREATE TABLE
nconway=# select distinct on (a) a, b, c from abc order by b, c, a;
ERROR: SELECT DISTINCT ON expressions must match initial ORDER BY
expressions
This works fine, of course:
nconway=# select distinct
Greg Stark [EMAIL PROTECTED] writes:
Do you really want:
select distinct on (b,c,a) a,b,c from abc order by b,c,a;
or is that you want
select * from (select distinct on (a) a,b,c order by a) order by
b,c,a;
If I understand you correctly, I don't think I would expect either.
- ORDER BY
Tom Lane [EMAIL PROTECTED] writes:
This was discussed before --- see the archives. I believe the
conclusion was that the results would actually be nondeterministic
if we used two sort steps (that's what the code comment means by
rather unpredictable).
Does the non-determinism you're
Andrew Dunstan [EMAIL PROTECTED] writes:
In normal operation the only thing that should be signalling a
backend is the postmaster.
Oh? What about LISTEN/NOTIFY?
-Neil
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose
Thomas Hallgren [EMAIL PROTECTED] writes:
I'm working on a pljava module. In it, I'd like to cache some allocated
structures (allocated using TopMemoryContext) using a string as the key. I
need a hash or binary-search table with dynamic size where I can store
arbitrary structures and then find
Simon Riggs [EMAIL PROTECTED] writes:
Select count(*) could be evaluated against any available index
sub-tables, since all that is required is to count the rows. That would
be significantly faster than a full file scan and accurate too.
PostgreSQL stores MVCC information in heap tuples only,
Adam Witney [EMAIL PROTECTED] writes:
I have one regression failure on 7.4.1, which does not occur with 7.4
[EMAIL PROTECTED] more src/test/regress/regression.diffs
*** ./expected/random.out Thu Feb 13 05:24:04 2003
--- ./results/random.outTue Dec 23 20:19:40 2003
Tom Lane [EMAIL PROTECTED] writes:
It might also be worthwhile to add another BM_FLAG bit that
specifically indicates a buffer is on the freelist, and
set/clear/test that at appropriate spots.
ISTM that BM_FREE should indicate this, or am I misunderstanding you?
-Neil
Tom Lane [EMAIL PROTECTED] writes:
It might be a good idea to rename BM_FREE to something else, perhaps
BM_UNPINNED, since I can recall being confused about what it meant
too.
If all it indicates is refcount == 0, ISTM we can just get rid of it
altogether, and just check the shared refcount
I've attached a (gzip'ed) patch that makes the following changes to
the buffer manager:
(1) Overhaul locking; whenever the code needs to modify the state
of an individual buffer, do synchronization via a per-buffer
meta data lock rather than the global BufMgrLock. For more
Tom Lane [EMAIL PROTECTED] writes:
This is a bug Jan introduced recently --- he forgot to modify the
shared memory setup code to allow space for the new data structures
used by ARC. Jan, would you mind fixing that soon? It's getting in
people's way.
Jan had asked that I include the fix for
Michael Brusser [EMAIL PROTECTED] writes:
Is there a way to force database to load a frequently-accessed table
into cache and keep it there?
No.
BTW, this idea has been suggested in the past, so check the archives
for the prior discussions on this topic. The usual response is that
the
Marc G. Fournier [EMAIL PROTECTED] writes:
if you think about it, the postmaster is actually aptly named,
since it is the process that sorts out the incoming connections and
assigns them to backend processes ... just like the postmaster does
with your mail ...
Right, hence the witty pun :-)
Tom Lane [EMAIL PROTECTED] writes:
I'm assuming that the original author of the GEQO code already did
that testing ...
Removing the code without bothering to verify this assumption is a
little unwise, IMHO: given the low quality of the rest of the GEQO
code, I wouldn't be surprised to learn
Tom Lane [EMAIL PROTECTED] writes:
Where are we going to find a representative test set of
dozen-or-more- way SQL join queries?
Interesting that you should mention that. I've been thinking for a
while that we need a much more extensive test suite for the query
optimizer. This would allow us to
Tom Lane [EMAIL PROTECTED] writes:
In theory there should be a section at the head of release.sgml
mentioning the major changes done-so-far, but for various reasons
this hasn't gotten installed in the 7.5 branch yet. (Look at the
CVS versions during 7.4 development to see how we did it last
Bruce Momjian [EMAIL PROTECTED] writes:
I am seeing the following compile failure in currrent CVS. Seems there
is a conflict between readline and psql's use of the xmalloc function
name.
This should be fixed in the latest CVS HEAD code (i.e. r1.82 of
common.c) -- can you make sure your
Greg Stark [EMAIL PROTECTED] writes:
But the compatibility with Oracle would be awfully nice.
Perhaps I'm missing something here: why is compatibility with Oracle
here particularly worth worrying about? Supporting the same
functionality as Oracle is good, but ISTM supporting the exact same
Michael Brusser [EMAIL PROTECTED] writes:
We tracked problem to this line in pgtcl.c:
putenv (PGCLIENTENCODING=UNICODE);
Changing this to
Tcl_PutEnv (PGCLIENTENCODING=UNICODE);
seems to be a good fix, so far we are not seeing any problems.
Looks good to me. Unless anyone else objects,
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
In what version of Postgres did the pg_stat_activity view appear?
7.2
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
David Helgason [EMAIL PROTECTED] writes:
I needed these, so I went and implemented them myself.
I didn't see any followup to this: do we want to include this in the
main tree, contrib/, or not at all?
-Neil (who has no opinion on the matter, but just wants to make sure
this doesn't fall through
While reviewing Andrew Dunstan's patch that implements the
log_disconnections GUC var, I noticed that tab-complete.c in psql
claims that only USERSET and possibly SUSET GUC variables should be
included in the list of variables that can be auto-completed.
That policy is clearly not followed:
Recently, I was surprised to learn that psql variables are case
sensitive. Furthermore, there is no error when one attempts to '\set'
a non-existent variable (arguably for good reason: I suppose it's too
late now to get rid of user-defined psql variables). That leads to
confusing situations like
Tom Lane [EMAIL PROTECTED] writes:
[ blinks... ] This is historical revisionism. Psql variables were
invented to provide user-defined variables; it is the predefined
ones that are a wart added to the mechanism, not vice versa.
The historical origins of the feature are no excuse for its
Tom Lane [EMAIL PROTECTED] writes:
I'm not by any means wedded to the USERSET and possibly SUSET
policy, but I would like to stop somewhere short of include
everything. Any thoughts?
Perhaps we could have two sets of variables: all the GUC vars (that
can be displayed via SHOW), and a subset
Chris KL recently pointed out to me that we currently don't raise an
error when attempting to cast a zero-length string to a float:
nconway=# select ''::float8;
float8
0
(1 row)
nconway=# select ''::float4;
float4
0
(1 row)
Similarly for oid:
nconway=# select
I can reproduce the following behavior with CVS HEAD.
1. Have a process do INSERTs into a table in a tight loop (I've
attached a trivial libpq app that does this)
2. In another session, repeatedly drop and re-create the table
that is being modified
You should see a
Neil Conway [EMAIL PROTECTED] writes:
1. Have a process do INSERTs into a table in a tight loop (I've
attached a trivial libpq app that does this)
Sorry, I was evidently a little too quick off the draw. A simple test
app is /really/ attached this time.
-Neil
#include stdio.h
Ramanujam H S Iyengar [EMAIL PROTECTED] writes:
Can i get any design documentation apart from the readme files and the
comments those are available with the source code .
Not really. There's some information in the Internals section of the
main docs:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Either way, we should make them a WARNING for 7.5, then error in
7.6.
Ok, I'll make this change soon.
If we end up marking more 7.5 changes using this mechanism
(i.e. deprecate for 7.5, disallow for 7.6), we could use an #ifdef
symbol to mark
Simon Riggs [EMAIL PROTECTED] writes:
Kenneth Marshall would like me to post this:
I agree that in order to manage today's large memory machines, we
need to have less contention in our buffer management strategies.
The two main main choke points are in the buffer hash table routines
and in the
Bruce Momjian [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Hmmm I'm not sure how you arrived at this wording for the TODO. How are
we defining a syntax error?
Parser error, I would say. Misspelling a table name, perhaps.
FWIW, a misspelled table name is plainly a semantic error, not
Jan Wieck [EMAIL PROTECTED] writes:
In the case of a postmaster crash, I think something in the system
is so wrong that I'd prefer an immediate shutdown.
I agree. Allowing existing backends to commit transactions after the
postmaster has died doesn't strike me as being that useful, and is
$ cd src/interfaces/ecpg
$ make
[ ... ]
bison -y -d preproc.y
mv -f y.tab.c ./preproc.c
mv -f y.tab.h ./preproc.h
/usr/bin/flex -o'pgc.c' pgc.l
pgc.l:979: warning, -s option given but default rule can be matched
-Neil
---(end of broadcast)---
Tom Lane [EMAIL PROTECTED] writes:
That's interesting, because I get no such warning here. What version
of flex are you using? (Mine is 2.5.4)
[EMAIL PROTECTED]:/home/nconway]% flex --version
flex 2.5.31
(The flex 2.5.31-22 debian package)
-Neil
---(end of
Peter Eisentraut [EMAIL PROTECTED] writes:
I think we had previously decided that we will not allow a random user
off the street to file bug reports into whatever system we end up
using.
Uh, why not? (And more to the point, why raise the barrier to entry on
reporting bugs?)
Individuals can
Jon Jensen wrote:
How would you do a rollback if an error occurred mid-query? How would you
keep your table from being a big pile of junk if a power failure happened
during the query?
As most non-MVCC database do: by writing WAL records.
In theory, it seems to me that we could implement an
Josh Berkus wrote:
D. One possible reservation may be integrating RT with GForge.
I'm confused. Are we considering moving core backend development over
to GForge as well, or just GBorg? (Personally the former doesn't
strike me as a good idea, at least initially.)
I think that the PostgreSQL
Simon Riggs wrote:
On the other hand, I was just about to change the wal_debug behaviour to
allow better debugging of PITR features as they're added.
That's a development activity. Enabling the WAL_DEBUG #ifdef by
default during the 7.5 development cycle would be uncontroversial, I
think.
I
It seems to me the following should Just Work:
nconway=# create table t1 (a timestamp);
CREATE TABLE
nconway=# insert into t1 values (now());
INSERT 17164 1
nconway=# insert into t1 values (now());
INSERT 17165 1
nconway=# insert into t1 values (now());
INSERT 17166 1
nconway=# insert into t1
From time to time, people on IRC ask for help with performance
problems, and the cause of the difficulty is ultimately traced to a
poor query plan that is chosen because default_statistics_target is
too low. While there will always need to be *some* tuning of the
statistics target by advanced
Tom Lane wrote:
This is something we need to consider, but we'll need more evidence
before making a choice. One thing that we have very little data about
is how much difference it makes in the quality of planner choices.
Right, but is there a practical way to actually get this data?
If the
Dennis Bjorklund [EMAIL PROTECTED] writes:
When UNSAFE_FLOATS is defined there is a check that float results
are within the min and max limits, which excludes values like
'Infinity', '-Infinity' and 'Nan'.
No, 'NaN' is legal float4/float8/numeric input whether UNSAFE_FLOATS
is defined or not.
Tom Lane [EMAIL PROTECTED] writes:
Nowadays, IEEE float math is nearly universal, and we would be
offering better functionality if we allowed access to Infinity and
Nan by default.
This is faulty reasoning: we *do* allow NaN by default (although
you're correct that we reject Infinity in float8
Dennis Bjorklund [EMAIL PROTECTED] writes:
In C one can set a signal handler to catch floating point exceptions
(SIGFPE). Without a handler you can get NaN and Infinity as the
result of mathematical operations.
Okay, I think this would be a reasonable set of behavior:
- define a new GUC
Tom Lane [EMAIL PROTECTED] writes:
That sounds okay. Also we might want to distinguish NaN from
Infinity --- I would expect most people to want zero-divide to
continue to get reported, for instance, even if they want to get
Infinity for overflow.
Yeah, good point.
This I disagree with. It
Bruce Momjian [EMAIL PROTECTED] writes:
I am seeing the following regression failure for current CVS. On my
OS, BSD/OS 4.3, it seems once you hit Infinity, you can't negate it.
Actually, I suspect the problem is that isinf() on your platform
returns 1 for any infinity (rather than -1 for
I get the following warning compiling CVS HEAD:
[neilc:/Users/neilc/pgsql]% make -C src/backend/utils/error all
[ ... ]
gcc -no-cpp-precomp -O0 -Winline -fno-strict-aliasing -g -Wall
-Wmissing-prototypes -Wmissing-declarations -I../../../../src/include
-I/sw/include -c -o elog.o elog.c -MMD
On 21-Mar-04, at 11:39 AM, Kris Jurka wrote:
Would it be possible to have the command completion tag for EXECUTE
return
the affected row count?
Yes, this has been suggested before -- for example:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg26787.html
I agree it would be a good idea,
1 - 100 of 1081 matches
Mail list logo
