Jeff wrote:
Do we have any numbers as to how much this will help things?
No, I haven't done any benchmarking yet (I might do some before I
leave for the summer, but it's not a priority...)
FWIW, the performance improvement from this patch won't be as large
as it might be, since Tom already
I've applied the list rewrite patch to CVS HEAD. I've also sent a
copy of the patch I applied to the -patches list.
Notes:
- the tree compiles without warnings and passes the regression
tests. I'm not aware of any bugs, regression failures, or compiler
warnings caused by the list rewrite patch
Does the following zero-column behavior strike anyone else as being a
little strange? I can take a look at fixing this, I'm just curious if
there's a consensus that the status quo isn't optimal.
(1)
neilc=# create table zero_col ();
CREATE TABLE
neilc=# select * from zero_col;
--
(0 rows)
--
With current sources, it appears that vpath builds (i.e. separate source
and build trees) are broken. make succeeds, but make install produces:
[neilc:/Users/neilc/build-pgsql]% make install
make -C doc install
make[1]: Nothing to be done for `install'.
make -C src install
make -C port install
Tom Lane wrote:
BTW, while you're messing with it, can you fix the random one-character
lossage that so frequently happens in the list of file names?
While we're asking for improvements to pgsql-committers, would it be
possible for you to make it easier to view the diff for a particular
CVS
Marc G. Fournier wrote:
I can't see this really being possible ... have you seen this on another
project?
Sure, it's quite common. There's a list of scripts that support this
kind of functionality at the bottom of this page:
http://www.badgers-in-foil.co.uk/projects/cvsspam/
So there are plenty
Bruce Momjian wrote:
Agreed, even if the URL is only valid for a week or so.
Why would the URL only be temporarily valid?
-Neil
---(end of broadcast)---
TIP 8: explain analyze is your friend
Marc G. Fournier wrote:
k, hasn't come through yet, but looked in the archives and the message
looks good ... missed a / for cvsweb, so fixed that ...
Looks good, but one minor quibble: the URL is to the cvsweb page for the
file in question, not the diff for the change to the file described by
Sander Steffann wrote:
All those links look messy IMHO. Maybe it's possible to give one link for
every directory instead one for every file?
The commit message ought to (and how does) contain a link directly to
the relevant diff, rather than to the cvsweb entry for the modified
file. Emitting
Marc G. Fournier wrote:
Tom appears to be against, everyone else seems to be for ... should we try
it and see how it works out?
Sure, although I personally think Andrew's suggestion of creating a
separate (non-archived) list that includes the full diff is the best
solution. That satisfies both
[ Sorry for the latency of my response, Chris -- this got buried in my
inbox... ]
Fabien COELHO wrote:
I don't know where these standards are available online... It seems they
are not available:-(
A copy that claims to represent an almost indistinuishable delta on the
actual SQL 2003 database
Gaetano Mendola wrote:
I well understand the reason to wait a 7.5 in order to delivery
BIG changes that are requiring a initdb, but I don't understand
why little enhancement can not be delivered in a 7.4.3 ( may be
with a short period with a 7.4.3beta ) like the vacuum delayed.
I don't think this
Alvaro Herrera Munoz wrote:
Those are PDFs AFAIR, not easily greppable
Not greppable, but any half-decent PDF viewer should have a search
feature that should allow much the same thing. Checking the index is
another way to go, although it is somewhat time-consuming.
I don't have access to an
I'll be away from PostgreSQL development from approximately the end of
May until August 20th. I won't be subscribed to any PG-related mailing
lists for that period. However, I'll still be accessible via email to
this address.
Have a great summer, everyone.
-Neil
---(end
On Sat, 2004-05-08 at 13:10, Gaetano Mendola wrote:
However an *add on* is an *add on* with not the same eligibility
of the main project
I'd suggest implementing the custom datatype first and packaging it
separately (say, via pgFoundry) -- it can always be moved into the core
distribution at
On 4-May-04, at 2:18 PM, David Fetter wrote:
I'd like to be able to run large batch-process jobs for caching, but
limit the total resource utilization on them, something like nice(1).
Better still would be some way to put a max on total resources be
able to allocate from that.
Does PostgreSQL
On 30-Apr-04, at 8:53 PM, Tatsuo Ishii wrote:
For me even September 1st does not seem too late. Major version up
bring users pains including backup/restore application
imcompatibilty... IMO to justify those pains we need to give users
major enhancements. Honestly I don't understand why we should
On 28-Apr-04, at 12:12 AM, Bruce Momjian wrote:
I never liked cell myself. It is too vague to me. But I see your
point that list_head you would think returns the head of the list, not
the first element in the list.
I'm not sure what you mean: list_head() returns the head of the list,
which is
On 27-Apr-04, at 10:07 PM, Tom Lane wrote:
[ ... on the topic of list_union(), list_union_int() and friends ]
I guess the real question in my mind is whether there is any true gain
in symmetry or readability by doing it this way.
I think there's a small gain: everything else being equal, an API
(To resurrect an old thread, I've finally got some time to devote to
this; I'll post a patch once I've got something ready for public
consumption.)
On 23-Mar-04, at 4:59 PM, Tom Lane wrote:
Let's see ... fleshing out this idea a bit, here's a rundown of all the
symbols in pg_list.h and
On 15-Apr-04, at 9:26 AM, Robert Turnbull wrote:
How can multiple SQL statements be included in one prepare command?
The goal is to reduce chatter between the client and server by
submitting an atomic tranasaction set.
You can submit multiple PREPARE commands in one query string (separated
by
On Thu, 2004-04-22 at 09:19, Shachar Shemesh wrote:
The license given in the web link you mention seems to mandate all
related work to be under the same license, which is nowhere near what
BSD means.
What license text do you think implies this?
-Neil
---(end of
Valgrind'ing the postmaster yields a fair number of errors. A lot of
them are similar, such as the following:
==29929== Use of uninitialised value of size 4
==29929==at 0x80AFB80: XLogInsert (xlog.c:570)
==29929==by 0x808B0A6: heap_insert (heapam.c:1189)
==29929==by 0x808B19D:
On Mon, 2004-04-19 at 02:16, Tom Lane wrote:
(Offhand I can't even find CREATE TABLE AS in SQL99...)
This is semi-OT, but CREATE TABLE AS is (new) in SQL2003. At few glance,
the spec's notion of the command is about the same as ours, except for a
few minor syntactic differences (e.g. the [ WITH
On Sun, 2004-04-11 at 17:10, Sean Chittenden wrote:
Should information hiding be done in psql(1) or should this be managed
by the backend and all logic kept out of psql(1)?
If the intent of this feature is security, it seems totally pointless to
implement it in psql (leaving aside whether it's
I'll be attending the MIT Sloan Innovation Lab Meeting at MIT on April
15 and 16. The topic of the meeting is Exploring the Inner Workings of
User Innovation Communities. Some other folks from the open-source
community will be there, including individuals from Apache, Red Hat, and
Ximian.
If
On 2-Apr-04, at 5:16 PM, Andrew Dunstan wrote:
If' we're going to have this shouldn't it be a proper command?
Why? What benefit would this offer over implementing this feature as a
function?
-Neil
---(end of broadcast)---
TIP 1: subscribe and
On 28-Mar-04, at 8:32 PM, Joe Conway wrote:
It looks like a great idea to me...
+ * XXX does this percentage need to be user-configurable?
...but I think the answer to the above is yes.
Is this really a parameter that we can expect administrators to be able
to understand and tune very
On 25-Mar-04, at 12:25 AM, Dustin Sallings wrote:
It's definitely not a magic tool that makes bad code good and
conflicting patches happy. It solves other problems, though.
I don't think anything mentioned in this thread so far would be an
enormous improvement over what we have now. However, I
On 25-Mar-04, at 3:03 PM, Dustin Sallings wrote:
I don't do Windows, but my understanding is that tla is as well
supported on Windows as postgres is.
David Wheeler disagrees:
A serious weakness of arch is that it doesn't work well on
Windows-based systems, and it's not clear if that will ever
On 25-Mar-04, at 8:18 PM, Sean Chittenden wrote:
I haven't read much in the last few months, but archives from 2002
suggested there wasn't much on the table in terms of making this
happen beyond adding a function that runs as a DBA to create users
(which I've done).
Well, the db_user_namespace
On 23-Mar-04, at 3:03 PM, Bruce Momjian wrote:
Does removing SET WITHOUT OIDS cause compatibility problems?
ALTER TABLE ... SET WITHOUT OIDS has not been removed.
-Neil
---(end of broadcast)---
TIP 2: you can get off all lists at once with the
I'd like to wrap up the linked list rewrite, and get the code into CVS
reasonably soon. If you're unfamiliar with the motivations for
redesigning the linked list code, check the archives for previous
discussions, such as:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg02204.html
On 23-Mar-04, at 10:31 PM, Tom Lane wrote:
How do you mean it's no longer the case? ListCell looks exactly like a
cons cell to me.
Sorry, thinko on my part. I meant to say that lcons() is a Lispy name,
which suggests a Lispy implementation. This is no longer the case.
While lcons() isn't that
Christopher Kings-Lynne wrote:
This has not yet been fixed...
Attached is a patch for this issue. I've checked with Chris, and this
patch allows the regression tests to pass on his machine. I also
updated float8-exp-three-digits expected file, but I wasn't able to
test these changes (I don't
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,
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
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
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
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
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
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
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
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
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
$ 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
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
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
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
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
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
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
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
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
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
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]
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,
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
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
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
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:
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
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
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
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,
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
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
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
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
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
[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
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
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
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,
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 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
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
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
601 - 700 of 1081 matches
Mail list logo
