Hi All,
In ExplainOnePlan(), we are calling ExecutorStart() and ExecutorEnd()
even if we are not doing EXPLAIN ANALYZE. Whereas, ExecutorRun() is called
only if we are ANALYZEing.
Can we avoid calls to Executor{Start|End}() here, or is it necessary to
call them even for non-ANALYZE case?
Tom Lane wrote:
>> We change libpq from time to time. Besides, how many DBs are there
that
>> match the name pattern /^conn:.*=/ ? My guess is mighty few. So I
don't
>> expect lots of surprise.
>
> Um, but how many DB names have an "=" in them at all?
>
> Basically what this proposal is about is
On 2006-12-13, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> On 2006-12-13, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> BTW, I think it's possible to prove that there need never be two for the
>>> case of both sides the same datatype.
>
>> Counterexample even f
On Fri, Dec 08, 2006 at 11:43:27AM -0500, Tom Lane wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> >> Generally, I try and configure the all* settings so that you'll get 1
> >> clock-sweep per checkpoint_timeout. It's worked pretty well, but I
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2006-12-13, Tom Lane <[EMAIL PROTECTED]> wrote:
>> BTW, I think it's possible to prove that there need never be two for the
>> case of both sides the same datatype.
> Counterexample even for a single data type: define an operator x =* y
> which i
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> I just noticed that defining LOCK_DEBUG causes a compile failure
Still another demonstration that Bruce's approach to removing "unused"
#includes does not work. Patched in HEAD ...
regards, tom lane
---(
On 2006-12-13, Tom Lane <[EMAIL PROTECTED]> wrote:
> I wrote:
Right offhand I cannot see a reason why there should be different
equality operators with the same sortops. (If anyone can come up with
a plausible scenario for that, stop me here...)
>
> BTW, I think it's possible to pro
On Tue, Dec 12, 2006 at 03:26:32PM -0500, Bruce Momjian wrote:
> Heikki Linnakangas wrote:
> > > The maintain_cluster_order patch is useful by itself, and handles an
> > > existing TODO regarding pulling pages out of WAL in a specified order to
> > > maintain clustering.
> >
> > Pull pages out of
While testing a PITR recovery, I discovered that recovery.conf doesn't
seem to allow specifying ' in the command string, making it hard to
protect the restore_command against problematic filenames (whitespace
etc.). This doesn't seem to be a problem for archive_command, which
allows \' (e.g. archiv
As usual, following item in the 8.1.5 release note is pretty vague:
* Efficiency improvements in hash tables and bitmap index scans(Tom)
Especially I'm wondering what was actually improved in bitmap index
scans. I see several commit messages regarding bitmap index scans, but
I cannot figure
Neil Conway wrote:
> On Tue, 2006-12-12 at 17:30 -0500, Bruce Momjian wrote:
> > * Have EXPLAIN ANALYZE highlight poor optimizer estimates
>
> > TODO updated:
> >
> > * Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and
> > actual row counts differ by a specified per
On Dec 13, 2006, at 12:33 , Michael Glaesemann wrote:
On Dec 13, 2006, at 8:45 , Tom Lane wrote:
the entire operator/function structure is built on the
assumption that there is, say, only one "=" between any two
datatypes.
You mean only on "=" between any two values of a given datatype?
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> We change libpq from time to time. Besides, how many DBs are there that
> match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't
> expect lots of surprise.
Um, but how many DB names have an "=" in them at all?
Basically what this pro
On Dec 13, 2006, at 8:45 , Tom Lane wrote:
the entire operator/function structure is built on the
assumption that there is, say, only one "=" between any two datatypes.
You mean only on "=" between any two values of a given datatype? Or
is there something else I'm missing? So what you're do
I just noticed that defining LOCK_DEBUG causes a compile failure (have
not delved into how to fix, but thought it would be worth noting at this
point!):
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -I.
-I../..
Casey Duncan wrote:
>
> I was speaking from and end-user point of view, but I see your point.
> It's certainly attractive to just patch libpq and be done. However,
> that does have the side-effect of implicitly propagating the behavior
> to all libpg client software. That may be more unpleasantly
On Dec 12, 2006, at 5:16 PM, Andrew Dunstan wrote:
Casey Duncan wrote:
On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Right. Here's the patch I just knocked up, which seems to Just
Work (tm) ;-)
The main objection I can see to this is that you'd ge
Casey Duncan wrote:
> On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
>
>> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>> Right. Here's the patch I just knocked up, which seems to Just
>>> Work (tm) ;-)
>>
>> The main objection I can see to this is that you'd get a fairly
>> unhelpful message if you i
On Tue, 2006-12-12 at 17:30 -0500, Bruce Momjian wrote:
> * Have EXPLAIN ANALYZE highlight poor optimizer estimates
> TODO updated:
>
> * Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and
> actual row counts differ by a specified percentage
I don't think this
I wrote:
>>> Right offhand I cannot see a reason why there should be different
>>> equality operators with the same sortops. (If anyone can come up with
>>> a plausible scenario for that, stop me here...)
BTW, I think it's possible to prove that there need never be two for the
case of both sides
On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Right. Here's the patch I just knocked up, which seems to Just
Work (tm) ;-)
The main objection I can see to this is that you'd get a fairly
unhelpful message if you intended a conninfo string and there w
I mentioned this a while back, now that 8.2 is out perhaps others will be more
interested in new code.
Currently Postgres regression tests only test functionality within a single
session. There are no regression tests that test the transaction semantics or
locking behaviour across multiple transa
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On Dec 13, 2006, at 7:56 , Tom Lane wrote:
>> Right offhand I cannot see a reason why there should be different
>> equality operators with the same sortops. (If anyone can come up with
>> a plausible scenario for that, stop me here...)
> I think th
On Dec 13, 2006, at 7:56 , Tom Lane wrote:
Right offhand I cannot see a reason why there should be different
equality operators with the same sortops. (If anyone can come up with
a plausible scenario for that, stop me here...) So what I'm thinking
about is a unique index on oprlsortop/oprrsor
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Right. Here's the patch I just knocked up, which seems to Just Work (tm) ;-)
The main objection I can see to this is that you'd get a fairly
unhelpful message if you intended a conninfo string and there was
anything wrong with your syntax (eg, misspelle
I am trying to create the libpq.a as a universal binary (both ppc and
intel macs). Does anyone have any information on this process?
Thanks,
Ted
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Tom Lane wrote:
Martijn van Oosterhout writes:
Does that mean that:
psql -d "service=myservice"
should Just Work(tm)? That would be nice.
Even more to the point,
psql "service=myservice"
which is why we want to overload dbname rather than any of the other
PQsetdbLogin parame
Martijn van Oosterhout writes:
> Does that mean that:
> psql -d "service=myservice"
> should Just Work(tm)? That would be nice.
Even more to the point,
psql "service=myservice"
which is why we want to overload dbname rather than any of the other
PQsetdbLogin parameters for this --- dbna
I noticed today that process_implied_equality() still contains an ugly
hack that should have been got rid of awhile ago: it assumes that
mergejoinable operators are named "=". This has been a bogus assumption
for several releases, as illustrated by this failure:
regression=# select * from text_tb
On Tue, Dec 12, 2006 at 05:44:07PM -0500, Andrew Dunstan wrote:
> Now I look at fe-connect.c more closely, I'm tempted just to try parsing
> the dbname param as a conninfo string, and if it doesn't work fall back
> on a plain dbname. I could greatly reduce the chance of following the
> failure p
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I have been working on providing psql with the ability to accept a libpq
conninfo string, so that the following now works for me:
psql "conn:service=sname user=uname"
Perhaps this should be implemented in libpq, not at the p
Richard Huxton wrote:
> Simon Riggs wrote:
> > Intermediate results are always better than none at all. I do understand
> > what a partial execution would look like - frequently it is the
> > preparatory stages that slow a query down - costly sorts, underestimated
> > hash joins etc. Other times it
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have been working on providing psql with the ability to accept a libpq
> conninfo string, so that the following now works for me:
> psql "conn:service=sname user=uname"
Perhaps this should be implemented in libpq, not at the psql level?
Otherwise y
I have been working on providing psql with the ability to accept a libpq
conninfo string, so that the following now works for me:
psql "conn:service=sname user=uname"
Instead of providing yet another switch, I overloaded the dbname
parameter so that if it has the recognised prefix the rema
Heikki Linnakangas wrote:
> Jim C. Nasby wrote:
> > On Thu, Dec 07, 2006 at 10:30:11AM +, Heikki Linnakangas wrote:
> >> I've cut a new version of the GIT patch I posted earlier, and collected
> >> all my dispersed todo-lists, post-it notes, performance results,
> >> supplementary patches etc.
On Tue, Dec 12, 2006 at 04:42:50PM +0100, Albe Laurenz wrote:
> Or do shared libraries on Unixware generally 'not remember'
> the libraries they were linked against (this would be strange).
It could be that whoever compiled libldap there did not include the
dependancies at link time. It is legal t
Gregory Stark <[EMAIL PROTECTED]> writes:
> It's a fundamental shift in the idea of the purpose of bgwriter. Instead of
> trying to suck i/o away from the subsequent checkpoint it would be responsible
> for all the i/o of the previous checkpoint which would still be in progress
> for the entire tim
> Tom Lane wrote:
>>
>> I like Kevin's settings better than what Jim suggests. If the bgwriter
>> only makes one sweep between checkpoints then it's hardly going to make
>> any impact at all on the number of dirty buffers the checkpoint will
>> have to write. The point of the bgwriter is to red
I have thought a while about this and I have some ideas.
Ideally, we would be able to trickle the sync of individuals blocks
during the checkpoint, but we can't because we rely on the kernel to
sync all dirty blocks that haven't made it to disk using fsync(). We
could trickle the fsync() calls,
On Tue, Dec 12, 2006 at 03:33:04PM +, Heikki Linnakangas wrote:
> BTW: This type of questions really belong to pgsql-general or
> pgsql-novice, this list is for discussing development of PostgreSQL itself.
^^
Indeed - I am truly feeling like a novice now...
Cheers,
Patrick
---
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Shouldn't that be
> AC_CHECK_LIB(ldap_r, ldap_simple_bind, [],
> [AC_MSG_ERROR([library 'ldap_r' is required for
> LDAP])],
> [$PTHREAD_LIBS $EXTRA_LDAP_LIBS])
Ooops, of course. Like I said, untested ;-)
All,
You may or may not be aware that Dan Langille of FreeBSD (and BSDCan) is
running a PostgreSQL conference in Ottawa this May:
http://www.pgcon.org/2007/
In one week, PGCon will start accepting paper and tutorial submissions.
Dan needs a committee ... ideally 4-6 people ... from the c
Olivier PRENANT wrote:
> When I swithed to the newest version og pgbuildfarm, I noticed that
> --with-ldap (now by defaut) didn't work on UnixWare.
>
> This is because, on Unixware, ldap needs lber and resolv.
Is libldap a static library on that system?
Or do shared libraries on Unixware gener
COALESCE returns the leftmost non-null value. Perhaps what you wanted
was sum(coalesce(b,0)) instead of coalesce(0,sum(b))
>>> On Tue, Dec 12, 2006 at 9:22 AM, in message
<[EMAIL PROTECTED]>, Patrick Welche
<[EMAIL PROTECTED]> wrote:
> Is this a bug, or don't I understand coalesce()?
>
> creat
"Patrick Welche" <[EMAIL PROTECTED]> writes:
> Is this a bug, or don't I understand coalesce()?
>
> select coalesce(0,sum(b)) from test where a=2; -- 0 !
>
> So when I use coalesce() with sum(), I always get the constant. I would
> have expected it only in the case where sum() returns null..
Co
Patrick Welche wrote:
Is this a bug, or don't I understand coalesce()?
create table test (a int, b int);
insert into test values (1,null);
insert into test values (2,1);
insert into test values (2,2);
select * from test; -- returns:
select sum(b) from test where a=1;
Is this a bug, or don't I understand coalesce()?
create table test (a int, b int);
insert into test values (1,null);
insert into test values (2,1);
insert into test values (2,2);
select * from test; -- returns:
select sum(b) from test where a=1; -- null
sel
>>> On Tue, Dec 12, 2006 at 3:22 AM, in message
<[EMAIL PROTECTED]>,
"Zeugswetter
Andreas ADI SD" <[EMAIL PROTECTED]> wrote:
>> > One thing I do worry about is if both postgresql and the OS
>> > are both delaying write()s in the hopes of collapsing them
>> > at the same time. If so, this would
Thank you very much : it works
-bash-3.00$ gmake check 2>&1 |tee traces_check8.2.0_gcc_121206_v2.log
... ... ...
test create_function_1... ok
triggers ... ok
... ... ...
===
All 103 tests passed.
===
The problems were those you found :
Hi,
On Tue, 2006-12-12 at 19:57 +0900, Tatsuhito Kasahara wrote:
> I think this was caused by a description mistake of
> "postgresql-test.patch".
Yeah, I just figured that while I was looking at what Tom did for FC-7
RPMs.
I committed the new patch to CVS.
Regards,
--
The PostgreSQL Company -
Hi!
I think this was caused by a description mistake of "postgresql-test.patch".
>
'/SLONY_PGS/PostgreSQL_8.2.0/BUILD/postgresql-8.2.0/src/test/regres/../../../contrib/spi/refint.so
>
> LANGUAGE C;
> CREATE FUNCTION check_foreign_key ()
> RETURNS trigger
> ! AS
>
'/SLONY_PGS/PostgreSQL
Hi Tom,
Thanks for your help,
I will try it ASAP and report maybe tonighgt CET.
Also, Makefile.port needs a little patch that I'll send to.
On Mon, 11 Dec 2006, Tom Lane wrote:
> Date: Mon, 11 Dec 2006 11:26:14 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Andrew Dunstan <[EMAIL PROTECTED]>
>
Ron Mayer wrote:
Jim C. Nasby wrote:
On usage, ISTM it would be better to turn on GIT only for a clustered
index and not the PK? I'm guessing your automatic case is intended for
SERIAL PKs, but maybe it would be better to just make that explicit.
Not necessarily; since often (in my tables at l
> > One thing I do worry about is if both postgresql and the OS
> > are both delaying write()s in the hopes of collapsing them
> > at the same time. If so, this would cause both to be experience
> > bigger delays than expected, and make checkpoints worse.
>
> That is my concern. Letting 30 sec
Hello List,
I have already posted an e-mail on the general mailing list but on the
advice of Devrim Gunduz ;-) , I try on this mailing list.
I try to generate the RPM from the src.rpm downloaded on the
postgresql.org web site. I work on an IA-64 server with Red Hat
Enterprise Linux 4 AS update
55 matches
Mail list logo
