> Tatsuo Ishii wrote:
> >>I agree with Tom here. I have used the Oracle NOWAIT feature in the
> >>past and think it is a great feature IMHO. But when you need to use it,
> >>you want it to apply very specifically to a single statement. Using a
> >>sledge hammer when you need a tweezers isn't
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Do these need to be fixed in backend/catalog/system_views.sql to have
> pg_catalog. before everything?
No, because the references are all resolved when the views are created.
We do have to be cautious about qualifying references that appear w
Do these need to be fixed in backend/catalog/system_views.sql to have
pg_catalog. before everything?
eg.
CREATE VIEW pg_rules AS
SELECT
N.nspname AS schemaname,
C.relname AS tablename,
R.rulename AS rulename,
pg_get_ruledef(R.oid) AS definition
FROM (pg_re
Tatsuo Ishii wrote:
I agree with Tom here. I have used the Oracle NOWAIT feature in the
past and think it is a great feature IMHO. But when you need to use it,
you want it to apply very specifically to a single statement. Using a
sledge hammer when you need a tweezers isn't the right way to g
Hi all,
I'm looking at ways to improve PG performance where index scans are
concerned. The layout of our database and our access habits really hit PG's
index code square in the chops. Many of our queries spend way too much time
waiting for disk seeks, and I believe this is fully caused by the wa
POSTGRESQL: Summary of Changes since last release (7.4.1)
--
18 Feb 2004
This is a summary of most changes since code versions marked 7_4_1. The
intention is to help everybody understand what's coming and what might
be affected, though most i
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
The question is whether we should have a GUC variable to control no
waiting on locks or add NO WAIT to specific SQL commands.
That's only a minor part of the issue. The major problem I have with
the patch is that it affects *all* locks, in
TODO updated:
< * Add GUC variable to prevent waiting on locks
> * Add NO WAIT option to various SQL commands
---
Barry Lind wrote:
> I agree with Tom here. I have used the Oracle NOWAIT feature in the
>
Larry Rosenman wrote:
-- Start of PGP signed section.
>
>
> --On Wednesday, February 18, 2004 13:56:14 -0500 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> > Tom Lane wrote:
>
> > The question is whether we should have a GUC variable to control no
> > waiting on locks or add NO WAIT to specifi
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The question is whether we should have a GUC variable to control no
> > waiting on locks or add NO WAIT to specific SQL commands.
>
> That's only a minor part of the issue. The major problem I have with
> the patch is that it affects
I agree with Tom here. I have used the Oracle NOWAIT feature in the
past and think it is a great feature IMHO. But when you need to use it,
you want it to apply very specifically to a single statement. Using a
sledge hammer when you need a tweezers isn't the right way to go.
thanks,
--Barry
Bruce Momjian wrote:
The question is whether we should have a GUC variable to control no
waiting on locks or add NO WAIT to specific SQL commands.
Does anyone want to vote _against_ the GUC idea for nowait locking. (We
already have two voting for such a variable.)
If there is no one except Tom, w
> The question is whether we should have a GUC variable to control no
> waiting on locks or add NO WAIT to specific SQL commands.
>
> Does anyone want to vote _against_ the GUC idea for nowait locking. (We
> already have two voting for such a variable.)
I vote against. We got bit by both the reg
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The question is whether we should have a GUC variable to control no
> waiting on locks or add NO WAIT to specific SQL commands.
That's only a minor part of the issue. The major problem I have with
the patch is that it affects *all* locks, including syst
Tom Lane wrote:
> =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> > The problem with adding NO WAIT to specific commands is that is
> > inheritly unflexible. I think this is why the community has agreed on
> > implementing it based on GUC.
>
> I recall no such agreement ..
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I did this, and changed the foreign keys to use it, but I haven't managed
> to build a fk case where I could actually detect a change in the plan
> chosen. Since the queries are only a simple scan on the one table I'm
> wondering if it's basically just m
"Dave Page" <[EMAIL PROTECTED]> writes:
> Ignoring potential OID wraparound problems (which we do in pgAdmin) this
> should work, assuming there is an OID column. I would suggest trying the
> following methods in sequence:
> 1) Use the tables primary key.
> 2) Use the OID (and check that only one
> > Ok, it seems to me there are several options here.
> > 1. Find out which is the primary key for the
> table. What
> > happens if the primary key is a multi-row thing?
> What happens
> > if there is no primary key?
>
> I guess you mean multicolumn? No different, you just
> need all columns i
> > Without checking into details, this sounds like it could be
> a broken
> > ming/msys installation. Are you on the latest release version?
> >
> > Also, check for the Makefile.port file manually. configure cleraly
> > thinks it has created it... If it's not there, check if you
> can create
> -Original Message-
> From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
> Sent: 18 February 2004 14:56
> To: Dave Page
> Cc: Hackers; PostgreSQL OLE DB development
> Subject: Re: [HACKERS] OIDs, CTIDs, updateable cursors and friends
>
> I'll have a look at that. How would updateable cur
Dave Page wrote:
-Original Message-
From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
Sent: 18 February 2004 14:10
To: Dave Page
Cc: Hackers; PostgreSQL OLE DB development
Subject: Re: [HACKERS] OIDs, CTIDs, updateable cursors and friends
I would, except I'm not sure how many queries
> -Original Message-
> From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
> Sent: 18 February 2004 14:10
> To: Dave Page
> Cc: Hackers; PostgreSQL OLE DB development
> Subject: Re: [HACKERS] OIDs, CTIDs, updateable cursors and friends
>
>
> I would, except I'm not sure how many queries I
Dave Page wrote:
-Original Message-
From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
Sent: 18 February 2004 13:18
To: Hackers; PostgreSQL OLE DB development
Subject: [HACKERS] OIDs, CTIDs, updateable cursors and friends
Would adding "OID" to the rows returned by each "Select"
call,
> -Original Message-
> From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
> Sent: 18 February 2004 13:18
> To: Hackers; PostgreSQL OLE DB development
> Subject: [HACKERS] OIDs, CTIDs, updateable cursors and friends
>
> Would adding "OID" to the rows returned by each "Select"
> call, and
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> I am about to redo the patch that would allow tagging of log lines
>> with info via a printf-style string.
>
>> Any comments or suggestions before I start?
>
> I think Bruce already applied the previous version of your patch.
Not that
Title: Message
Without checking into details, this sounds like it could be a broken
ming/msys installation. Are you on the latest release
version?
Also,
check for the Makefile.port file manually. configure cleraly thinks it has
created it... If it's not there, check if you can create symbo
26 matches
Mail list logo
