On Fri, 21 May 2004, Tom Lane wrote:
Also, the new setup where the subject line is the first line of the
commit message seems cool to me, but if we're going to feed multiple
projects' commit messages into the same list then we'd better add the
project name to the subject.
Done
Marc G.
RHL 9.0
cvs HEAD, fresh update
make maintainer-clean
./configure --with-java --prefix=/home/grant/bin/pgsql/ \
--with-integer-datetimes --enable-debug --enable-cassert
make
yields:
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../src/include
Hi,
When you do this:
CREATE DATABASE test TEMPLATE master;
It doesn't copy any per-database GUC variables, created by the ALTER
DATABASE master SET var TO val; command.
Should it?
Chris
---(end of broadcast)---
TIP 7: don't forget to increase
I get this:
gmake[4]: Entering directory
`/space/1/home/chriskl/pgsql/src/backend/access/gist'
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../../src/include -c -o gist.o gist.c -MMD
In file included from
[EMAIL PROTECTED] wrote:
We do not want to open up the BSD vs GPL debate, but keeping PG as a BSD
license does take an amount of accounting.
I was using GPL as an example, as it was mentioned earlier in the
thread. My comments hold for *any* license, including (at least in the
UK; unfair
On Thu, 2004-05-20 at 19:59, Gaetano Mendola wrote:
Greg Copeland wrote:
On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote:
On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote:
fact that checkpoints, vacuum runs and pg_dumps bog down their machines
to the state where simple
I may have removed a few too many #include sys/time.h lines.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
I have binary install from snapshot from the other night on WINDOWS 2000
PRO and had same problem.
|-+--
| | Merlin Moncure |
| | [EMAIL PROTECTED]|
| | ne.com|
| |
In the current build on the anon cvs server, if I try to \d a table from
psql, the backend comes down. I played with the query a bit and
discovered any query using '~' operator in the where clause on any table
(catalog or otherwise) causes an immediate backend crash.
Can anybody confirm that
I downloaded it this morning around 8:00 AM CENTRAL TIME. Thanks for the
builds by the way!
|-+--
| | Merlin Moncure |
| | [EMAIL PROTECTED]|
| | online.com|
| |
I have binary install from snapshot from the other night on WINDOWS
2000
PRO and had same problem.
well, I'm the one compiling the snapshot :), so I trying to confirm that
I have not busted anything...when did you download the snapshot, though?
I switched to gcc 3.4 yesterday, was it earlier
Merlin Moncure [EMAIL PROTECTED] writes:
In the current build on the anon cvs server, if I try to \d a table from
psql, the backend comes down. I played with the query a bit and
discovered any query using '~' operator in the where clause on any table
(catalog or otherwise) causes an immediate
Merlin Moncure [EMAIL PROTECTED] writes:
In the current build on the anon cvs server, if I try to \d a table
from
psql, the backend comes down. I played with the query a bit and
discovered any query using '~' operator in the where clause on any
table
(catalog or otherwise) causes an
On 05/20/04:20/4, Tom Lane wrote:
It's true that this setup doesn't allow non-SRFs to get at the econtext,
but I'm not sure that they need to.
The only thing my goal has in common with getting at the econtext is the ability
to register a callback that can clean up my fn_extra at a relatively
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm a bit concerned about driving such a change in behavior off nothing
more than whether the statement is named or not.
Would it be better to bite the bullet and bump the protocol version,
adding a new field to Parse to control this
James William Pye [EMAIL PROTECTED] writes:
On 05/20/04:20/4, Tom Lane wrote:
It's true that this setup doesn't allow non-SRFs to get at the econtext,
but I'm not sure that they need to.
The only thing my goal has in common with getting at the econtext is
the ability to register a callback
Is there a downloadable version of the different postgresql mailling
lists? Or even just individual files for different months? I would like
to have a copy of possible, and lots of other OSS projects offer this, but
we don't, or at least I can't find it on the site. Did I miss it?
Thanks,
You and me both, I'd like a copy of this too.
Dave
On Fri, 2004-05-21 at 13:58, Matthew T. O'Connor wrote:
Is there a downloadable version of the different postgresql mailling
lists? Or even just individual files for different months? I would like
to have a copy of possible, and lots of other
Now that we have control of our own timezone code, one of the first
things I'd like to do with it is replace time_t with pg_time_t defined
as (signed) int8. This would allow us to handle timezone calculations
outside the 1904-2038 range, and in particular eliminate the bizarre
behaviors that
Tom Lane [EMAIL PROTECTED] writes:
select * from mytable where entry_time = $1;
The planner will take a seqscan when it sees this because it is worried
about the downside if a large fraction of the table is being selected.
I wonder if it would make sense for the planner to be smarter
Greg Stark [EMAIL PROTECTED] writes:
If the planner had the expected value as well as the variance of the cost
distribution then it might realize that in this case for instance that the
penalty for guessing wrong with an index scan is only going to be a small
slowdown factor, perhaps 2-4x
Tom Lane wrote:
Au contraire --- a full-table index scan can be vastly slower than a
full-table seqscan. I think it's wishful thinking to assume that
picking an indexscan is the right thing when we don't know any better.
I wish we could get this basic truth across to users somehow - I have
there are currently no downloadable files ... I have to re-work archives
to add them back in, as there used to be such ...
On Fri, 21 May 2004, Dave Cramer wrote:
You and me both, I'd like a copy of this too.
Dave
On Fri, 2004-05-21 at 13:58, Matthew T. O'Connor wrote:
Is there a
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't like that at all. Do the planning using the given parameters,
but save the plan. Otherwise you have substantially pessimized the
behavior for the case where an unnamed statement is reused.
How often is the unnamed
Oliver Jowett [EMAIL PROTECTED] writes:
This leads to my next problem (which was one of the original reasons I
went with node replacement): don't we get different performance between
a parameterized query and an equivalent unparameterized query in cases
such as this? :
SELECT * FROM
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
This leads to my next problem (which was one of the original reasons I
went with node replacement): don't we get different performance between
a parameterized query and an equivalent unparameterized query in cases
such as this? :
SELECT
Oliver Jowett [EMAIL PROTECTED] writes:
Ok, so something like this?
1) eval_const_expressions takes a list of parameter values and does
Param to Const replacement if given parameters.
2) The main planner does not pass parameters to eval_const_expressions.
3) When the selectivity functions
27 matches
Mail list logo
