Hi,
On Thu, 6 Oct 2005, Philip Yarra wrote:
On Thu, 6 Oct 2005 12:32 am, Devrim GUNDUZ wrote:
Thanks for the report. It will fixed in CVS and all the RPM sets later
today. Always feel free to send me a patch if you want, I can apply your
patch, too.
OK, you got my previous email about why
Hello all,
I want to set a system level flag for my own purposes.
What changes in initdb.c or any other files are expected.
And When I will run my postgresql , how I get that system level flag.
On Thu, 6 Oct 2005, Devrim GUNDUZ wrote:
Hi,
On Thu, 6 Oct 2005, Philip Yarra wrote:
On Thu,
Hi,
I used info from current_user for log. about some operations (who, when,
..). What I can see, current_user is equal current_role function. I had
problem with it, because user (if is member of any group role) can
change
his identity. example: peter is member of role users. But peter can
On Wed, 2005-10-05 at 00:50 -0400, Tom Lane wrote:
Qingqing Zhou [EMAIL PROTECTED] writes:
1/ What types of prefix compression shall we support?
Given the requirement of datatype independence, this idea seems a
complete nonstarter to me...
It would be possible to compress on similar
On K, 2005-10-05 at 13:21 -0400, Ron Peacetree wrote:
First I wanted to verify that pg's IO rates were inferior to The Competition.
Now there's at least an indication that someone else has solved similar
problems. Existence proofs make some things easier ;-)
Is there any detailed programmer
On K, 2005-10-05 at 19:54 -0400, Ron Peacetree wrote:
+I made the from left field suggestion that perhaps a pg native fs
format would be worth consideration. This is a major project, so
the suggestion was to at least some extent tongue-in-cheek.
This idea is discussed about once a year on
Apparently, there's currently no way to perform conditional compiling
dependent on the version of pgsql. Currently we're facing the problem
that ParseDateTime changed its parameters between 8.0.3 and 8.0.4,
breaking backward compatibility (for good reasons in this case).
IMHO it's quite
Now I've asked for the quickest path to detailed
understanding of the pg IO subsystem. The goal being to get
more up to speed on its coding details. Certainly not to
annoy you or anyone else.
Basically pg does random 8k (compile time blocksize) reads/writes only.
Bitmap and sequential
Hi all,
consider this view:
CREATE OR REPLACE VIEW v_current_connection AS
SELECT ul.id_user
FROM user_login ul,
current_connection cc
WHERE ul.id_user = cc.id_user;
And this is the explain on a usage of that view:
# explain select * from v_current_connection_test where
Hi Dmitry!
On 27 Sep 05 at 16:16, Dmitry (Dmitry Karasik) wrote to Andrew Dunstan:
Andrew Meanwhile, I will observe that this very desirable feature needs
Andrew an interface with spi_fetchrow()
I re-worked the patch ( http://www.karasik.eu.org/misc/plperl.diff ) and
now there's also
hi
I want to know which files to be explored so as to do case insensitive
joining in case of nested loop joins
esha
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to
On Thu, Oct 06, 2005 at 01:32:32AM -0400, Neil Conway wrote:
On Thu, 2005-06-10 at 01:14 -0400, Tom Lane wrote:
The idea of blocking during commit until shmem becomes available might
work. There's some issues here about transaction atomicity, though:
how do you guarantee that all or none
Am Donnerstag, 6. Oktober 2005 12:50 schrieb Andreas Pflug:
Apparently, there's currently no way to perform conditional compiling
dependent on the version of pgsql. Currently we're facing the problem
that ParseDateTime changed its parameters between 8.0.3 and 8.0.4,
breaking backward
On Thu, Oct 06, 2005 at 10:50:29AM +, Andreas Pflug wrote:
Apparently, there's currently no way to perform conditional compiling
dependent on the version of pgsql. Currently we're facing the problem
that ParseDateTime changed its parameters between 8.0.3 and 8.0.4,
breaking backward
-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
Sent: 06 October 2005 13:47
To: Andreas Pflug
Cc: pgsql-hackers@postgresql.org; Dave Page
Subject: Re: [HACKERS] version dependent compilation
Am Donnerstag, 6. Oktober 2005 12:50 schrieb Andreas Pflug:
Neil Conway [EMAIL PROTECTED] writes:
However, I don't really like the idea of blocking the backend for a
potentially significant amount of time in a state half-way between
committed and ready for the next query.
I wonder whether we could use something comparable to pg_multixact
or
Gaetano Mendola [EMAIL PROTECTED] writes:
CREATE OR REPLACE VIEW v_current_connection AS
SELECT ul.id_user
FROM user_login ul,
current_connection cc
WHERE ul.id_user = cc.id_user;
# explain select * from v_current_connection_test where
sp_connected_test(id_user) = FALSE;
why
On Wed, Oct 05, 2005 at 04:55:51PM -0700, Luke Lonergan wrote:
You've proven my point completely. This process is bottlenecked in the CPU.
The only way to improve it would be to optimize the system (libc) functions
like fread where it is spending most of it's time.
Or to optimize its IO
On Thu, 6 Oct 2005 05:10 am, elein wrote:
Generally a short sed (or perl if you like) script will fix
these up. But it is really pretty obscure trail for people
to find the exact problem.
Yeah, it's not that it's hard to fix when you know where to look, but my aim
is to produce a site
hi
i would like to know whether the feature for resource control is there or
not... i mean controlling the allocated resources in pgsql sothat when a
shortage is going tobe happened.. it automatically prompts the admin to
kill some of the processes or preempt some of the resources ...
Simon Riggs [EMAIL PROTECTED] writes:
It might be worth teaching the optimiser that if it has an index on an
immutable function that if we have WHERE x = k and a functional index on
f(x) then we can access the functional index with
f(x) = f(k), as long as we also reapply the original WHERE
On Thu, Oct 06, 2005 at 09:12:58AM -0400, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
However, I don't really like the idea of blocking the backend for a
potentially significant amount of time in a state half-way between
committed and ready for the next query.
I wonder whether
First of all, I'd like to give a name to the thing that a backend listens
to. The code talks about listening to a relation, but as the
comments there point out, the name doesn't actually identify a relation.
I'm going to call it a topic from now on.
I'd like to point out that we don't really
On Thu, Oct 06, 2005 at 08:53:25AM +0100, Simon Riggs wrote:
It would be possible to compress on similar values, since we know the
output of the comparison in the final stage of the sort of the index
build. That wouldn't need to rely upon anything to do with the datatype,
since they are equal
Dear all,
Does anyone know how index searching work in PG. I've explored the
source code of PG, for btree, for searching, it will call the
functions in file btcompare.c. As I've made a printf in the functions
of the file btcompare.c. When I compile and run PG, it get into
loop,. the
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
CREATE OR REPLACE VIEW v_current_connection AS
SELECT ul.id_user
FROM user_login ul,
current_connection cc
WHERE ul.id_user = cc.id_user;
# explain select * from v_current_connection_test where
sp_connected_test(id_user)
Heikki Linnakangas [EMAIL PROTECTED] writes:
It might make sense to change the semantics so that we never lose a
notification, if we're going to implement NOTIFY 'msg', but that's another
discussion.
That's pretty much a given --- the ability to pass some payload data in
notifications has
On Thu, Oct 06, 2005 at 09:06:59AM -0500, smile khmer wrote:
Dear all,
Does anyone know how index searching work in PG. I've explored the
source code of PG, for btree, for searching, it will call the
functions in file btcompare.c. As I've made a printf in the functions
of the file
Hi all,
Whenever a function get called it receive one parameter
as
PG_FUNCTION_ARG ( as in nbtcompare.c )
I am not getting how it is interpreted and how it is used ??
thank u
--
--
| Sandeep Satpal |
| M.Tech Student |
| Lab 212 KReSIT |
--
sandeep satpal [EMAIL PROTECTED] writes:
Whenever a function get called it receive one parameter
as
PG_FUNCTION_ARG ( as in nbtcompare.c )
I am not getting how it is interpreted and how it is used ??
It's a pointer to a struct containing the actual arguments.
You might find it helpful to
- Original Message -
From: Alvaro Herrera [EMAIL PROTECTED]
To: smile khmer [EMAIL PROTECTED]
Subject: Re: [HACKERS] PG function call
Date: Thu, 6 Oct 2005 10:30:37 -0400
On Thu, Oct 06, 2005 at 09:06:59AM -0500, smile khmer wrote:
Dear all,
Does anyone know how index searching
Hi all,
nodeNestloop.c executes nested loop joins. After getting a pair of inner
and outer it test the inner and outer tuples to see if they satisfy the
node's qualification using function ExecQual(joinqual, econtext, false).
ExecQual evaluates join conditions one at a time.It captures one
On Thu, Oct 06, 2005 at 09:14:02PM +0530, Esha Palta wrote:
ExecQual evaluates join conditions one at a time.It captures one
condition and passes it to function ExecEvalExpr which is actually a
macro that invokes another function evalfunc(a method of ExprState
structure).
It's not a method
On Thu, Oct 06, 2005 at 10:01:55AM -0500, smile khmer wrote:
but when I write the output to file (not standard out put), it won't finish,
so I interupted and
there're more than 50.000 lines,...
What did you expect? PostgreSQL uses indexes for everything from
looking up functions to finding
Andreas,
pg relys on the OS readahead (== larger block IO) to do efficient IO.
Basically the pg scan performance should match a dd if=file of=/dev/null
bs=8k,
unless CPU bound.
FWIW, we could improve performance by creating larger write blocks when
appropriate, particularly on Unixes like
On Wed, Oct 05, 2005 at 07:54:15PM -0400, Ron Peacetree wrote:
I asked some questions about physical layout and format translation
overhead being possibly suboptimal that seemed to be agreed to, but
specifics as to where we are taking the hit don't seem to have been
made explicit yet.
This
i had to deal with oracle in the past couple of days (*mega sigh*)
i have seen a very interesting feature which would make sense for
PostgreSQL users.
currently we have:
test=# \h PREPARE TRANSACTION
Command: PREPARE TRANSACTION
Description: prepare the current transaction for two-phase
Andreas,
On 10/6/05 3:56 AM, Zeugswetter Andreas DAZ SD [EMAIL PROTECTED]
wrote:
pg relys on the OS readahead (== larger block IO) to do efficient IO.
Basically the pg scan performance should match a dd if=file of=/dev/null
bs=8k,
unless CPU bound.
Which it is. Postgres will currently do a
On Thu, 2005-10-06 at 09:38 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
It might be worth teaching the optimiser that if it has an index on an
immutable function that if we have WHERE x = k and a functional index on
f(x) then we can access the functional index with
f(x)
On Thu, 2005-10-06 at 19:13 +0200, Hans-Jürgen Schönig wrote:
i had to deal with oracle in the past couple of days (*mega sigh*)
i have seen a very interesting feature which would make sense for
PostgreSQL users.
currently we have:
test=# \h PREPARE TRANSACTION
Command: PREPARE
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
in oracle it is possible to comment transactions:
COMMIT COMMENT 'ORA-2PC-CRASH-TEST-n';
if we added the possibility to comment prepared transactions it would be
far easier for DBAs to find out what to do with prepared
Martijn van Oosterhout kleptog@svana.org writes:
Indeed, one of the things on my list is to remove all the lseeks in
favour of pread. Halving the number of kernel calls has got to be worth
something right? Portability is an issue ofcourse...
Being sure that it's not a pessimization is another
People,
After writing dblink-ldap (http://pgfoundry.org/projects/dblink-ldap),
several people have contacted me asking if this will give LDAP
authentication to PostgreSQL, because they need this. And this is before
I've even released it, so apparantly there are a lot of people who want
this.
Dear all,
I made some change ot the function in btcompare.c and compiling and
installation is success, but when I start to run with
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
I've got this error message : creating template1 database in
/usr/local/pgsql/data/base/1 ... FATAL:
Tom Lane [EMAIL PROTECTED] writes:
I like your suggestion of topic for the notify name, and am tempted to
go fix the documentation to use that term right now ...
Fwiw, I think the more conventional word here would be channel.
But whatever.
--
greg
---(end of
Martijn van Oosterhout kleptog@svana.org writes:
Are we awfully worried about people still using 2.0 kernels? And it
would replace two calls with three in the worst case, we currently
lseek before every read.
That's utterly false.
regards, tom lane
On Thu, Oct 06, 2005 at 03:57:38PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Indeed, one of the things on my list is to remove all the lseeks in
favour of pread. Halving the number of kernel calls has got to be worth
something right? Portability is an issue
On Thu, Oct 06, 2005 at 03:57:38PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Indeed, one of the things on my list is to remove all the lseeks in
favour of pread. Halving the number of kernel calls has got to be worth
something right? Portability is an issue
On Thu, Oct 06, 2005 at 04:25:11PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Are we awfully worried about people still using 2.0 kernels? And it
would replace two calls with three in the worst case, we currently
lseek before every read.
That's utterly false.
On Wed, Oct 05, 2005 at 03:40:43PM -0700, Qingqing Zhou wrote:
We do the prefix sharing when we build up index only, never on the fly.
So are you saying that inserts of new data wouldn't make any use of
this? ISTM that greatly reduces the usefulness, though I'm not objecting
because compression
Jim C. Nasby wrote:
Instead of ignoring the first line of a COPY FROM ... WITH CSV HEADER,
what about allowing the first line to be used as a list of field names?
This means you wouldn't have to include field order in the COPY command
if the names matched field names in the table.
It was
In both the 8.1beta2 and using a build from this morning's
dev snapshot, this query ran slower than expected:
select count(*)
from DbTranRepository AS dtr
inner join DbTranLogRecord AS dtlr
on (dtlr.countyNo = dtr.countyNo
and dtlr.tranImageSeqNo = dtr.tranImageSeqNo
Just before 8.1beta2 went out, Neil made the following changes:
Rename pg_complete_relation_size() to
pg_total_relation_size(), for the sake of brevity and clarity.
Make pg_reload_conf(), pg_rotate_logfile(), and pg_cancel_backend()
return a boolean rather
I don't get a vote - but I do want to suggest, as a user, that I get
generally annoyed with the presence of interfaces with names that
were chosen for historical reasons, but are maintained only for
compatibility, and either never did, or no longer apply.
I'd rather you left it fixed. Returning
On Thu, 2005-10-06 at 21:27 -0400, Tom Lane wrote:
Just before 8.1beta2 went out, Neil made the following changes:
Rename pg_complete_relation_size() to
pg_total_relation_size(), for the sake of brevity and clarity.
Make pg_reload_conf(), pg_rotate_logfile(), and
On Thu, 6 Oct 2005, [EMAIL PROTECTED] wrote:
I don't get a vote - but I do want to suggest, as a user, that I get
generally annoyed with the presence of interfaces with names that
were chosen for historical reasons, but are maintained only for
compatibility, and either never did, or no longer
On Thu, 6 Oct 2005, Tom Lane wrote:
Just before 8.1beta2 went out, Neil made the following changes:
Rename pg_complete_relation_size() to
pg_total_relation_size(), for the sake of brevity and clarity.
Make pg_reload_conf(), pg_rotate_logfile(), and pg_cancel_backend()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The plausible alternatives seem to be:
1. Leave it as-is.
I vote for this. It's not an ideal situation, but the names should
be changed at some point - better now than later, as it reduces the
lifetime of the bad names. Put a large warning
On Thu, Oct 06, 2005 at 09:27:55PM -0400, Tom Lane wrote:
Just before 8.1beta2 went out, Neil made the following changes:
Rename pg_complete_relation_size() to
pg_total_relation_size(), for the sake of brevity and clarity.
Make pg_reload_conf(), pg_rotate_logfile(),
[EMAIL PROTECTED] wrote:
I don't get a vote - but I do want to suggest, as a user, that I get
generally annoyed with the presence of interfaces with names that
were chosen for historical reasons, but are maintained only for
compatibility, and either never did, or no longer apply.
I'd rather
1. Leave it as-is.
+1 From here..
Joshua D. Drake
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG -
Kevin Grittner [EMAIL PROTECTED] writes:
In both the 8.1beta2 and using a build from this morning's
dev snapshot, this query ran slower than expected:
There's a known issue that the planner tends to overestimate the cost of
inner-index-scan nestloops, because it doesn't allow for the strong
On Thu, Oct 06, 2005 at 10:57:33PM -0300, Marc G. Fournier wrote:
On Thu, 6 Oct 2005, [EMAIL PROTECTED] wrote:
I don't get a vote - but I do want to suggest, as a user, that I get
generally annoyed with the presence of interfaces with names that
were chosen for historical reasons, but are
Jim C. Nasby wrote:
On Wed, Oct 05, 2005 at 03:40:43PM -0700, Qingqing Zhou wrote:
We do the prefix sharing when we build up index only, never on the fly.
So are you saying that inserts of new data wouldn't make any use of
this? ISTM that greatly reduces the usefulness, though I'm not
On Thu, 6 Oct 2005, Jim C. Nasby wrote:
On Wed, Oct 05, 2005 at 03:40:43PM -0700, Qingqing Zhou wrote:
We do the prefix sharing when we build up index only, never on the fly.
So are you saying that inserts of new data wouldn't make any use of
this? ISTM that greatly reduces the
I don't see NUM_USER_DEFINED_LWLOCKS defined in 8.0 or 8.1, so what
system do you propose to allow you to set this value?
---
Marc Munro wrote:
-- Start of PGP signed section.
Tom,
Thanks for your reponse. Unless I am
Bruce Momjian pgman@candle.pha.pa.us writes:
I don't see NUM_USER_DEFINED_LWLOCKS defined in 8.0 or 8.1, so what
system do you propose to allow you to set this value?
I'd be willing to add the proposed patch in 8.1 (style note:
NUM_USER_DEFINED_LWLOCKS should be set in pg_config_manual.h not
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I don't see NUM_USER_DEFINED_LWLOCKS defined in 8.0 or 8.1, so what
system do you propose to allow you to set this value?
I'd be willing to add the proposed patch in 8.1 (style note:
NUM_USER_DEFINED_LWLOCKS should be set in
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
I'd be willing to add the proposed patch in 8.1 (style note:
NUM_USER_DEFINED_LWLOCKS should be set in pg_config_manual.h not
lwlock.h).
Shouldn't it be something we can put in postgresql.conf?
No more than any of the other
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
I'd be willing to add the proposed patch in 8.1 (style note:
NUM_USER_DEFINED_LWLOCKS should be set in pg_config_manual.h not
lwlock.h).
Shouldn't it be something we can put in postgresql.conf?
No more
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
With only one known request for a user-allocated lock, it's hard to
justify the overhead of a GUC variable.
True, but are people going to recompile PostgreSQL to use this feature?
Seems they would have to.
How you figure that?
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
With only one known request for a user-allocated lock, it's hard to
justify the overhead of a GUC variable.
True, but are people going to recompile PostgreSQL to use this feature?
Seems they would have to.
On Thu, 2005-06-10 at 23:56 -0400, Bruce Momjian wrote:
True, but are people going to recompile PostgreSQL to use this feature?
Seems they would have to.
They would need to recompile PostgreSQL to use more than the default
number of user-defined LWLocks, which seems perfectly reasonable to me.
Dear All,
I use '$libdir/lo' for manage my PostgreSQL Large Object. It work fine for me to get and put Large Object from and to database. However I found something that may not correct when I try to backup my data. It seem that I cannot delete Large Object from database. It seem the thing I can
I am absolutely sure that I never changed any of the enable_xxx
settings other than enable_mergejoin during these tests. The only
other setting I played with was random_page_cost, but the nested
loop query always chose the plain index scan in my tests.
There was one odd thing. I started
Just my two cents... but I prefer option 1.
2005/10/6, Alvaro Herrera [EMAIL PROTECTED]:
On Thu, Oct 06, 2005 at 10:57:33PM -0300, Marc G. Fournier wrote:
On Thu, 6 Oct 2005, [EMAIL PROTECTED] wrote:
I don't get a vote - but I do want to suggest, as a user, that I get
generally annoyed
76 matches
Mail list logo
