I was originally planning to revise pg_aggregate along the same lines
as pg_proc and so forth: add an aggnamespace column and fix the search
code to be namespace-aware. But it seemed a tad annoying that standard
function lookups would thereby incur *two* namespace-aware searches:
one in pg_aggreg
Af far as I know Oracle doesn't have any short cut (along the lines of
what is being discussed in this thread) for this operation. However
Oracle is more efficient in providing the answer than postgres currently
is. While postgres needs to perform a full scan on the table, Oracle
will only n
> In addition, this seems to be the "canonical paper" on snapshot
> isolation:
>
> http://citeseer.nj.nec.com/berenson95critique.html
There is an excellent, more recent paper, Generalized Isolation Level
Definitions (http://citeseer.nj.nec.com/adya00generalized.html).
Fernando Nasser writes:
> I does not _have_ to be "public", so we can just avoid the issue
> by adding a pg_ prefix to public, common or something else.
> It is a PostgreSQL concept anyway.
No, it's an Oracle concept.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > If at all, SET commands should behave like everything else.
> > If done inside a transaction, they have to rollback.
>
> I have thought of a scenario that may be sufficient to justify fixing
> SETs to roll back on transaction a
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Could we get out of this by defining that "timeout" is
> > automatically reset at next statement end?
>
> I was hoping to avoid that, because it seems like a wart. OTOH,
> it'd be less of a wart than the global changes of
> Or, as I suggested above, extend the SELECT (and other querys?) syntax
> seems reasonable. More so than the non-standard 'use this index, really'
> types of extensions that other RDBMSs provide, that we've rightly avoided.
I think we need timeout for all statement.
--
Bruce Momjian
> Hmm, so essentially we'd have to convert all codes >= 0x80 to prevent
> them from being mistaken for parts of multibyte sequences?
Yes.
> Ugh, but
> you're probably right. It looks to me like byteaout does the reverse
> already.
As for the new UNKNOWN data type, that seems a good thing for
m
Hiroshi Inoue wrote:
>
> > We can't do that. Accordingly to the SQL if you are user HIROSHI
> > and write "SELECT * FROM a;" the table is actually "HIROSHI.a".
> >
> > This must work for people who are using SQL-schemas in their databases
> > or we would have a non-conforming implementation o
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 3:42 PM
To: Peter Bierman
Cc: Dann Corbit; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Peter Bierman <[EMAIL PROTECTED]> writes:
> ... Your comment: "An
> accurate cardinal
Peter Bierman <[EMAIL PROTECTED]> writes:
> ... Your comment: "An
> accurate cardinality figure can greatly enhance the optimizer's
> ability to perform joins in the correct order" was intriguing, and I'd
> be interested in Tom's thoughts on just that bit.
Approximate figures are quite sufficient
Joe Conway <[EMAIL PROTECTED]> writes:
> But still, doesn't that mean roughly twice as much memory usage for each
> copy of the string? And I seem to remember Jan saying that each datum
> winds up having 4 copies in memory. It ends up impacting the practical
> length limit for a bytea value.
Well
> I don't think your idea would work for a concurrent user setup where
> people have different transactions started at different times with
> different amounts of changes inside each transaction.
>
> That's why it would have to be tracked on a "per connection" basis for
> all the tables.
I tried
Larry Rosenman writes:
> On Fri, 2002-04-05 at 16:55, Peter Eisentraut wrote:
> > We had discussed a while ago that it might be a good idea to compile with
> > debugging symbols by default, at least when using GCC. Personally, I
^^
> With t
Tom Lane wrote:
>> Yuck! At that point you're no better off than converting to hex
>> (and worse off than converting to base64) for storage.
>
>
> No; the *storage* is still compact, it's just the I/O representation
> that's not.
Yeah, I realized that after I pushed send ;)
But still, does
> -Original Message-
> From: Fernando Nasser
>
> Hiroshi Inoue wrote:
> >
> > Tom Lane wrote:
> > >
> > > Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > > > I don't object to use a search path to resolve unqualified
> > > > function, type etc names. But it is very siginificant for
> > > >
On Fri, 2002-04-05 at 16:55, Peter Eisentraut wrote:
> We had discussed a while ago that it might be a good idea to compile with
> debugging symbols by default, at least when using GCC. Personally, I
> think that that would be a good idea, for users and developers alike.
>
> If we go with that,
We had discussed a while ago that it might be a good idea to compile with
debugging symbols by default, at least when using GCC. Personally, I
think that that would be a good idea, for users and developers alike.
If we go with that, I'd like to implement a new target 'install-strip'
that strips
(Sorry that my previous post did not reach the pgsql-hackers list, I
sent it from the wrong address and was thus not considered a
subscriber)
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> But I am a bit puzzled. How can a serializable transaction be
> performed in a MVCC system? I realize the Or
Joe Conway <[EMAIL PROTECTED]> writes:
>> This scenario is probably why Tatsuo wants PQescapeBytea to octalize
>> everything with the high bit set; I'm not sure there's any lesser way
> Yuck! At that point you're no better off than converting to hex (and
> worse off than converting to base64) fo
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>
>>I think you're correct that in a client/database encoding mismatch
>>scenario, there would be bigger problems. Thoughts on this?
>
>
> This scenario is probably why Tatsuo wants PQescapeBytea to octalize
> everything with the high bi
> >> It would be nice if total table cardinality could be maintained live.
> >
> > How would this work with MVCC?
>
> It wouldn't. That's why it's not there. Under MVCC, table cardinality
> is in the eye of the beholder...
That makes me curious how oracle implements it. I was under the impressi
-Original Message-
From: Rod Taylor [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 12:35 PM
To: Dann Corbit; Tom Lane
Cc: Doug McNaught; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Not to mention it only increases the speed of:
SELECT count(*) FROM foo
At 12:08 PM -0800 4/5/02, Dann Corbit wrote:
>I guess that this model can be viewed as "everything is a snapshot".
>It seems plain that the repercussions for a data warehouse and for
>reporting have not been thought out very well. This is definitely
>very, very bad in that arena. I suppose that
-Original Message-
From: Jon Grov [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 12:54 PM
To: Dann Corbit
Cc: Mike Mascari; Doug McNaught; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> That's interesting. If Or
-Original Message-
From: Mike Mascari [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 12:44 PM
To: Dann Corbit
Cc: Doug McNaught; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Dann Corbit wrote:
>
> I guess that this model can be viewed as "everything is a
Dann Corbit wrote:
>
> I guess that this model can be viewed as "everything is a snapshot".
> It seems plain that the repercussions for a data warehouse and for
> reporting have not been thought out very well. This is definitely
> very, very bad in that arena. I suppose that reporting could sti
Not to mention it only increases the speed of:
SELECT count(*) FROM foo;
and not:
SELECT count(*) FROM foo WHERE bar;
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are y
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> At any rate, there is clearly a concept of cardinality in any case.
Certainly. The count(*) value is perfectly well defined within any one
transaction. We *could*, if we wanted to, implement bookkeeping logic
that would keep track of the number of row
-Original Message-
From: Doug McNaught [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 11:55 AM
To: Dann Corbit
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> How would this work with MVCC?
> >>
> Whenever a c
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> How would this work with MVCC?
> >>
> Whenever a commit occurs, the pending inserts are totaled into the sum
> and the pending deletes are subtracted. It can be a list in memory or
> whatever. Maybe you are referring to the old (expired) rows begin
>
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> If this is true (even after a commit) then MVCC is a very bad thing. No
> transactions occur, and two people ask the same question yet get
> different answers. Doesn't that scare anyone? That would mean (among
> other things) that Postgresql cannot b
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> How many accounts are 90 days overdue? Bill says 78 and Frank says 82.
> Who is right and how can we know?
If Bill and Frank look at exactly the same instant (ie, from read-only
transactions started at the same time), they will get the same answer.
If
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 11:37 AM
To: Doug McNaught
Cc: Dann Corbit; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
Doug McNaught <[EMAIL PROTECTED]> writes:
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
-Original Message-
From: Doug McNaught [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 11:30 AM
To: Dann Corbit
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestion for optimization
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> It would be nice if total table cardinality could
Doug McNaught <[EMAIL PROTECTED]> writes:
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
>> It would be nice if total table cardinality could be maintained live.
> How would this work with MVCC?
It wouldn't. That's why it's not there. Under MVCC, table cardinality
is in the eye of the beholder...
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> It would be nice if total table cardinality could be maintained live.
> So (after the initial vacuum) we update the cardinality for each table
> in the system table (or perhaps add an entry to the table itself).
> There are two reasons why this is an im
Ross J. Reedstrom wrote:
> On Fri, Apr 05, 2002 at 11:19:04AM -0500, Tom Lane wrote:
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> > > Could we get out of this by defining that "timeout" is
> > > automatically reset at next statement end?
> >
> > I was hoping to avoid that, because it
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Could we get out of this by defining that "timeout" is
> > automatically reset at next statement end?
>
> I was hoping to avoid that, because it seems like a wart. OTOH,
> it'd be less of a wart than the global changes of
Jan Wieck <[EMAIL PROTECTED]> writes:
> If at all, SET commands should behave like everything else.
> If done inside a transaction, they have to rollback.
I have thought of a scenario that may be sufficient to justify fixing
SETs to roll back on transaction abort. Consider
BEG
It would be nice if total table cardinality could be maintained live.
So (after the initial vacuum) we update the cardinality for each table
in the system table (or perhaps add an entry to the table itself).
There are two reasons why this is an important optimization. Firstly,
it is a psychologic
Joe Conway <[EMAIL PROTECTED]> writes:
> I think you're correct that in a client/database encoding mismatch
> scenario, there would be bigger problems. Thoughts on this?
This scenario is probably why Tatsuo wants PQescapeBytea to octalize
everything with the high bit set; I'm not sure there's an
Tom Lane wrote:
>
> OTOH, I was surprised to read your message because I had assumed the
> damage was being done much further upstream, viz during collection of
> the query string by pq_getstr(). Do we need to think twice about that
> processing, as well?
>
I just looked in pq_getstr() I see:
Joe Conway <[EMAIL PROTECTED]> writes:
> I could take a look at this. Any guidance other than "faithfully
> preserving the contents of a C string"?
Take textin/textout, remove multibyte awareness? Actually the hard
part is to figure out which of the existing hardwired calls of textin
and textou
On Fri, Apr 05, 2002 at 11:19:04AM -0500, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Could we get out of this by defining that "timeout" is
> > automatically reset at next statement end?
>
> I was hoping to avoid that, because it seems like a wart. OTOH,
> it'd be
Tom Lane wrote:
>>INSERT INTO t1(bytea_col) VALUES('characters produced by
>>PQescapebytea'::bytea);
>
>
> Probably that would cause the error to disappear, but it's hardly a
> desirable answer.
>
> I wonder whether this says that TEXT is not a good implementation of
> type UNKNOWN. That choic
Fernando Nasser <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>> You know, I'm kinda surprised that the spec doesn't define a CURRENT_SCHEMA
>> variable you can query???
> Maybe because it would be the same as CURRENT_USER.
It'd probably make sense for us to have one, though, give
Hi Oleg,
My understanding of patent law (in a generalised way) means that for any
country in which you're granted a patent on something, these days it
effectively means you've got control of the usage of that particular
thing.
So, if Prof. Rudolf Bayer has a patent on the algorithm for UB-Tree's
Hiroshi Inoue wrote:
>
> Tom Lane wrote:
> >
> > Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > > I don't object to use a search path to resolve unqualified
> > > function, type etc names. But it is very siginificant for
> > > users to be able to be sure what tables they are handling.
> >
> > I re
Christopher Kings-Lynne wrote:
>
> > I really don't buy this argument; it seems exactly comparable to
> > arguing that the notion of current directory in Unix is evil, and
> > that users should be forced to specify absolute paths to every
> > file that they reference.
>
> You know, I'm kinda sur
Joe Conway <[EMAIL PROTECTED]> writes:
> But the error comes from pg_verifymbstr. Since bytea has no encoding
> (it's just an array of bytes afterall), why does pg_verifymbstr get
> applied at all to bytea data?
Because textin() is used for the initial conversion to an "unknown"
constant --- se
Jan Wieck <[EMAIL PROTECTED]> writes:
> Could we get out of this by defining that "timeout" is
> automatically reset at next statement end?
I was hoping to avoid that, because it seems like a wart. OTOH,
it'd be less of a wart than the global changes of semantics that
Bruce is pro
Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>
>>PQescapebytea() is not multibyte aware and will produce bad multibyte
>>character sequences. Example:
>>I think 0x89 should be converted to '\\211' since 0x89 of 0x8950 is
>>considered as "non printable characters".
>
>
> Hmm, so es
On Sat, 6 Apr 2002, Justin Clift wrote:
> Hi everyone,
>
> For anyone who's interested in the patent status of UB-Tree's, here is
> further info.
>
> :-)
I dont' understand that. Does it means someone has no rights to
implement the algorithm in any form ? Who has patented an idea of
relational d
Hi everyone,
For anyone who's interested in the patent status of UB-Tree's, here is
further info.
:-)
Regards and best wishes,
Justin Clift
Original Message
Subject: AW: UB-Tree's and patents
Date: Thu, 4 Apr 2002 17:41:10 +0200
From: "Rudolf Bayer" <[EMAIL PROTECTED]>
To: "
On Thu, 4 Apr 2002, Bruce Momjian wrote:
> It that acceptable to the JDBC folks? It requires two "SET timeout = 0"
> statements, one after the statement in the transaction, and another
> after the transaction COMMIT WORK.
That's fine, though probably about as much work as just implementing the
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> PQescapebytea() is not multibyte aware and will produce bad multibyte
> character sequences. Example:
> I think 0x89 should be converted to '\\211' since 0x89 of 0x8950 is
> considered as "non printable characters".
Hmm, so essentially we'd have to conve
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> istm that the general strategy for changing column types would require
> marking a column as dead and adding a new column to replace it, or
> writing an atomic copy / modify / replace operation for tables which
> modifies tuples as it proceeds, or ?? J
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Yes, I now think that saving the SET commands that are ignored in a
> > > transaction and running them _after_ the transaction completes may be
> > > the best thing.
> >
> > No, that's just plain ridiculous.
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> Hmm. Seems like that case, and the various ones involving adjustment of
>> char/varchar length by hacking atttypmod, would be useful to support via
>> ALTER COLUMN even if we don't have a full implementation. Essentially
>> this would be t
Patch applied. Thanks.
---
Nicolas Bazin wrote:
> Here is the description:
>
> When a macro is replaced by the preprocessor, pgc.l reaches a end of file, which is
>not the actual end of the file. One side effect of that
Patch applied. Thanks.
---
Oliver Elphick wrote:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> -Forwarded Message-
>
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Cc: [EMAIL
62 matches
Mail list logo
