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
> > >general
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 testing
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 ca
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.
Tom Lane wrote:
> Bruce Momjian 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 yo
Bruce Momjian 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? The proposed defau
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 entries in pg_config_
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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
lwlock.h). However, it
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 m
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 usefu
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, 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
"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 stron
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 - http://www.command
[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 r
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_logfi
-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 warnin
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()
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 ap
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(), a
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 it
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
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" = "dt
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 deba
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
On Thu, Oct 06, 2005 at 04:25:11PM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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.
Oops, y
On Thu, Oct 06, 2005 at 03:57:38PM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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...
>
On Thu, Oct 06, 2005 at 03:57:38PM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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...
>
Martijn van Oosterhout 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
---(end of
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 o
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: duplic
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.
You
Martijn van Oosterhout 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 issue. I note
=?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
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: PREPA
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
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 current
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 co
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
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 Sol
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
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 "me
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
c
- 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 i
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 t
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 |
--
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 b
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 ha
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_connec
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 messag
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 eq
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 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 w
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 WHE
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 ...
thanku
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 inst
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 hand
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;
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 pg_
> -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:
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
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 compat
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
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 [EM
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
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
sp_connected_
> 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 sequentia
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 helpfu
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 o
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 progra
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
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
74 matches
Mail list logo
