Bruce Momjian wrote:
Is there a TODO here?
Maybe!? It's one of these premature things noone can tell by now. So the
TODO would be "investigation" for now.
Jan
---
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
> I'm
On Fri, Aug 15, 2003 at 06:57:24AM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > Is there a reasonable way to add an optional param or two to mark
> > time zones, or should that just the application programmer's
> > hassle?
> The return type should be timestamptz, which mak
Is there a TODO here?
---
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > I'm thinking instead of a way to "cache" entire executors for this. Each
> > SPI plan used during a transaction would need it's own execu
Bruno Wolff III wrote:
> How about something like the following:
> select * from t
> where a >= a1 and b >= b1
>order by a, b limit 1 offset 1;
Well, this may have recently changed, but the offset clause is not
suitable for arbitrary jumps over large tables. Essentially, pg does an
i
Has the idea of putting the infrastructure in place to allow a full pathname
to be fed to DT_SONAME been totally killed?
That is the one remaining issue I have right now.
I think we should put the infrastructure in place, and allow the UnixWare
and SCO OpenServer ports use it for now. (both of t
Yep,
Just tested it with a full check out...
GREAT JOB!
Thanks to uou all!
On Thu, 14 Aug 2003, Larry Rosenman wrote:
> Date: Thu, 14 Aug 2003 22:23:17 -0500
> From: Larry Rosenman <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: UnixWare on Current CVS: Success!
>
On Fri, Aug 15, 2003 at 13:42:23 -0400,
Merlin Moncure <[EMAIL PROTECTED]> wrote:
>
> Example:
> I have a table t with columns a, b, c. I have values a1, b1, c1 for
> those columns and would like to know the next value in the table when
> ordered by a, b. I have values a1, b1, and oid1 and w
There are a couple of routines in parse_oper.c that are intended to look
up appropriate '=' and '<' operators given a datatype OID. These are
used in quite a variety of places, for example to determine the
semantics of GROUP BY.
It's bothered me for some time that these routines depend on actuall
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> I have no idea what that numModes++ line is doing there.
I think the notion is that the lock modes are counted in 1-based
numbering; the copy loop starts at 0 so it needs an extra iteration.
Look at the uses of numLockModes for evidence. (Note the extra z
Dann Corbit wrote:
-Original Message-
From: Andreas Pflug [mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 11:36 AM
To: Dann Corbit
Cc: Stephan Szabo; PostgreSQL-development
Subject: Re: [HACKERS] [GENERAL] 7.4Beta
Dann Corbit wrote:
Simplification of bulk operations can be
> -Original Message-
> From: Andreas Pflug [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 15, 2003 11:36 AM
> To: Dann Corbit
> Cc: Stephan Szabo; PostgreSQL-development
> Subject: Re: [HACKERS] [GENERAL] 7.4Beta
>
> Dann Corbit wrote:
>
> >Simplification of bulk operations can be very
Jan Wieck <[EMAIL PROTECTED]> writes:
> I'm thinking instead of a way to "cache" entire executors for this. Each
> SPI plan used during a transaction would need it's own executor, and I
> don't know offhand what type and how much resources an executor requires
> (I think it's only some memory th
In lmgr.c you have a static LOCKMASK LockConflicts[] with 9
elements in it.
You call LockMethodTableInit() with that pointer, and
MAX_LOCKMODES - 1 (10 - 1 = 9)
That calls LockMethodInit with the same arguments, but it does
numModes++.
So you basicly have a for loop that looks like:
for (i = 0;
Christoph Haller <[EMAIL PROTECTED]> writes:
> Today I've d-loaded PostgreSQL 7.3.4.
> I've seen in
> $PGSQLD/doc/html/index.html
> it still says
> Copyright (C) 1996-2002
> shouldn't it be 2003?
We only update the copyright notices when we are preparing a major
release. (Bruce just did it a week
Gmane,
I just checked in a fix to the jdbc driver for this. The problem was
that the connection termination message was being passed the wrong
length, which really didn't have any other adverse side effect than this
message in the log, since the connection was no longer being used.
thanks,
--
Dann Corbit wrote:
Simplification of bulk operations can be very important for customers
(on the other hand). For the CONNX tool set, we offer an escape on
INSERT/SELECT that performs the operation in bulk mode.
There are serious downsides to bulk operations also (such as not being
logged and the
> -Original Message-
> From: Andreas Pflug [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 15, 2003 10:49 AM
> To: Stephan Szabo
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] [GENERAL] 7.4Beta
>
>
> Stephan Szabo wrote:
>
> >I don't know if there will be or not, but in one case
Tom Lane wrote:
Today it occurred to me that we could look in pg_opclass for a default
btree opclass for the datatype. If we find one, then the Equal and Less
members of the opclass are the operators we want. (If we don't find
one, we could try for a default hash opclass, which would give us Equa
Stephan Szabo wrote:
I don't know if there will be or not, but in one case it's a single table
select with constant values, in the other it's probably some kind of scan
and subselect. I'm just not going to rule out the possibility, so we
should profile it in large transactions with say 100k single
Can anybody help me with this? (sorry
for posting on hackers)
I need to be able determine the next row based on a non
unique key (index). I have solved
this problem, but I would like to know if there is a simpler solution. For those of you who have ever dealt
with COBOL, this is an on
On Fri, 15 Aug 2003, Andreas Pflug wrote:
> Stephan Szabo wrote:
>
> >On Fri, 15 Aug 2003, Andreas Pflug wrote:
> >
> >>Stephan Szabo wrote:
> >>
> >>>Well, I think single inserts might be more expensive (because the query is
> >>>more involved for the table joining case) using a statement level t
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Andreas Pflug wrote:
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Andreas Pflug wrote:
Stephan Szabo wrote:
That really needs to be rewritten to do a single check over the table
rather than running the constraint for every row.
Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
select * from fk where not exists(select * from pk where pk.key=fk.key)
and key is not null;
(doing seq scan/subplan doing index scan - which is probably close to the
current system)
Actually, even that would probably be noticeably better
Today I've d-loaded PostgreSQL 7.3.4.
I've seen in
$PGSQLD/doc/html/index.html
it still says
Copyright (C) 1996-2002
shouldn't it be 2003?
Regards, Christoph
PS
I've sent this to [EMAIL PROTECTED] before.
But in return I've got
Your message to pgsql-docs has been delayed, and requires the approva
On Fri, 15 Aug 2003, Andreas Pflug wrote:
> Stephan Szabo wrote:
>
> >On Fri, 15 Aug 2003, Andreas Pflug wrote:
> >
> >
> >
> >>Stephan Szabo wrote:
> >>
> >>
> >>
> >>>That really needs to be rewritten to do a single check over the table
> >>>rather than running the constraint for every row. I
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Andreas Pflug wrote:
Stephan Szabo wrote:
That really needs to be rewritten to do a single check over the table
rather than running the constraint for every row. I keep meaning to get
around to it and never actually do. :( I'm not sure that in
On Fri, 15 Aug 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > select * from fk where not exists(select * from pk where pk.key=fk.key)
> > and key is not null;
> > (doing seq scan/subplan doing index scan - which is probably close to the
> > current system)
>
> Actually, eve
On Fri, 15 Aug 2003, Andreas Pflug wrote:
> Stephan Szabo wrote:
>
> >That really needs to be rewritten to do a single check over the table
> >rather than running the constraint for every row. I keep meaning to get
> >around to it and never actually do. :( I'm not sure that in practice
> >you'll
On Fri, 15 Aug 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Fri, 15 Aug 2003, Christopher Kings-Lynne wrote:
> >> I can also attest to the horrendously long time it takes to restore the ADD
> >> FOREIGN KEY section...
>
> > That really needs to be rewritten to do a sin
David Fetter <[EMAIL PROTECTED]> writes:
> Is there a reasonable way to add
> an optional param or two to mark time zones, or should that just the
> application programmer's hassle?
The return type should be timestamptz, which makes the transformation
timezone-independent.
Stephan Szabo <[EMAIL PROTECTED]> writes:
> select * from fk where not exists(select * from pk where pk.key=fk.key)
> and key is not null;
> (doing seq scan/subplan doing index scan - which is probably close to the
> current system)
Actually, even that would probably be noticeably better than the
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Fri, 15 Aug 2003, Christopher Kings-Lynne wrote:
>> I can also attest to the horrendously long time it takes to restore the ADD
>> FOREIGN KEY section...
> That really needs to be rewritten to do a single check over the table
> rather than running the
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 3. Set up a long-lived cache internal to the array functions that can
>> translate element type OID to the needed lookup data, and won't leak
>> memory across repeated calls. This is not the fastest or most general
>> solution, but it see
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Christopher Kings-Lynne wrote:
I throw last nights backup at it. Data went in in about 1/2 an hour then
the
constraints went in and they took at age. about 2 hours.
Is there anyway to speed up the database constraint code? Because qui
> We've talked about stuff like that in the past, but we seem to generally
> get stuck about how to specify it. If we add it to the alter table add as
> an option then we're generating statements that are almost like a standard
> sql statement, but not quite, and some people didn't like that. A se
> We've talked about stuff like that in the past, but we seem to generally
> get stuck about how to specify it. If we add it to the alter table add as
> an option then we're generating statements that are almost like a standard
> sql statement, but not quite, and some people didn't like that. A se
On Fri, 15 Aug 2003, Christopher Kings-Lynne wrote:
> > We've talked about stuff like that in the past, but we seem to generally
> > get stuck about how to specify it. If we add it to the alter table add as
> > an option then we're generating statements that are almost like a standard
> > sql sta
> > 1. Add the FK to the table BEFORE COPYing data
> > 2. Use the old update blah set reltriggers = 0 trick
> > 3. restore the data
> > 4. Undo step 2
>
> The problem with that is that I think the reltriggers=0 trick only works
> if you're superuser, I thought that's why the trigger disabling becam
> > I can also attest to the horrendously long time it takes to restore the
ADD
> > FOREIGN KEY section...
>
> That really needs to be rewritten to do a single check over the table
> rather than running the constraint for every row. I keep meaning to get
> around to it and never actually do. :( I
On Fri, 15 Aug 2003, Christopher Kings-Lynne wrote:
> > > 1. Add the FK to the table BEFORE COPYing data
> > > 2. Use the old update blah set reltriggers = 0 trick
> > > 3. restore the data
> > > 4. Undo step 2
> >
> > The problem with that is that I think the reltriggers=0 trick only works
> > i
On Thu, 14 Aug 2003, Stephan Szabo wrote:
> That really needs to be rewritten to do a single check over the table
> rather than running the constraint for every row. I keep meaning to get
> around to it and never actually do. :( I'm not sure that in practice
> you'll get a better plan at restore
41 matches
Mail list logo
