> Jan, regression is not a test of the level a developer would use to make
> sure his code works. It is merely to make sure the install works on a
> limited number of cases.
News to me! If anything, I don't think a lot of the current regression
tests are comprehensive enough! For the SET/DROP
> > thought out way of predicting/limiting their size. (2) How the heck do
> > you get rid of obsoleted cached plans, if the things stick around in
> > shared memory even after you start a new backend? (3) A shared cache
> > requires locking; contention among multiple backends to access that
> >
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> case 1: "immutable"
> >> case 2: "mutable", or perhaps "stable"
> >> case 3: "volatile"
>
> > Since they've changed anyway, how about dropping the silly "is" in front
> > of the names?
>
> "volatile" would c
> Updating pg_attribute per se is not so hard --- just store new copies of
> all the rows for the table. However, propagating the changes into other
> places could be quite painful (I'm thinking of column numbers in stored
> constraints, rules, etc).
>
> It seems to me that reducing the column to
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> My profiles show that the work spent in the scanner is really minuscule
> compared to everything else.
Under ordinary circumstances I think that's true ...
> (The profile data is from a run of all the regression test files in order
> in one session.
Tom Lane writes:
> We do have some numbers suggesting that the per-character loop in the
> lexer is slow enough to be a problem with very long literals. That is
> the overhead that might be avoided with a special protocol.
Which loop is that? Doesn't the scanner use buffered input anyway?
> H
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> case 1: "immutable"
>> case 2: "mutable", or perhaps "stable"
>> case 3: "volatile"
> Since they've changed anyway, how about dropping the silly "is" in front
> of the names?
"volatile" would conflict with a C keyword. Possibly
Tom Lane writes:
> case 1: "immutable"
> case 2: "mutable", or perhaps "stable"
> case 3: "volatile"
Since they've changed anyway, how about dropping the silly "is" in front
of the names?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Curious -- I was previously using ~1 week old sources, and I was
> > unable to reproduce the problem (using either the original
> > test-case or the one provided above: neither has any problems).
> > When I built the current CVS code, b
Neil Conway <[EMAIL PROTECTED]> writes:
> Curious -- I was previously using ~1 week old sources, and I was
> unable to reproduce the problem (using either the original
> test-case or the one provided above: neither has any problems).
> When I built the current CVS code, both test-case exhibits the
I will apply shortly because pg_dump is broken. I will give it 8 hours.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
--
Jan Wieck wrote:
> > Oh, interesting, maybe we should just leave it alone.
>
> As said, I have to look at the code. I'm pretty sure that it
> currently will not use hundreds of digits internally if you
> use only a few digits in your schema. So changing it isn't
> that dange
Tatsuo Ishii wrote:
> > Jan Wieck wrote:
> > > > The hard limit is certainly no more than 64K, since we store these
> > > > numbers in half of an atttypmod. In practice I suspect the limit may
> > > > be less; Jan would be more likely to remember...
> > >
> > > It is arbitrary of course. I d
On Fri, 12 Apr 2002 19:24:21 -0400
"Neil Conway" <[EMAIL PROTECTED]> wrote:
> When I built the current CVS code, both test-case exhibits the
> problem quite obviously. Therefore, it seems that the problem
> has been introduced recently.
The problem was introduced here:
--
revisio
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > I think I made my point clear enough, that I consider calling
> > these functions just once is plain sloppy. But that's just
> > my opinion. What do others think?
>
> I don't have a problem with the current length of the n
Thomas Lockhart wrote:
> ...
> > It is my understanding that RPM does run that test. My main issue is
> > why does numeric have to be so much larger than the other tests? I have
> > not heard that explained.
>
> afaict it is not larger. It *does* take more time, but the number of
> tests is rel
On Fri, 12 Apr 2002 18:59:33 -0400
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> I said:
> > This will generate the problem:
>
> > create table t1 (f1 int primary key);
>
> > create table t2 (f1 int references t1);
>
> Actually, I find that I get the double declaration of t1_pkey even
> witho
Jan Wieck <[EMAIL PROTECTED]> writes:
> I think I made my point clear enough, that I consider calling
> these functions just once is plain sloppy. But that's just
> my opinion. What do others think?
I don't have a problem with the current length of the numeric test.
The original fo
I said:
> This will generate the problem:
> create table t1 (f1 int primary key);
> create table t2 (f1 int references t1);
Actually, I find that I get the double declaration of t1_pkey even
without t2. Either we're not using quite the same sources, or the
problem is platform-depen
Bruce Momjian wrote:
> Jan Wieck wrote:
> > You forgot who wrote that code originally. I feel alot
> > better WITH the tests in place :-)
> >
> > And if it's merely to make sure the install worked, man who
> > is doing source installations these days and runs the
>
Neil Conway <[EMAIL PROTECTED]> writes:
> However, when I created a table using the commands above and then
> dumped it again, I got a dump that worked properly:
> ...
> If you can give me a reproduceable test-case, I'll fix the bug.
Sigh ... I should take my own advice about checking that I've d
...
> It is my understanding that RPM does run that test. My main issue is
> why does numeric have to be so much larger than the other tests? I have
> not heard that explained.
afaict it is not larger. It *does* take more time, but the number of
tests is relatively small, or at least compatible
...
> Jan, regression is not a test of the level a developer would use to make
> sure his code works. It is merely to make sure the install works on a
> limited number of cases. Having seen zero reports of any numeric
> failures since we installed it, and seeing it takes >10x times longer
> than
Jan Wieck wrote:
> You forgot who wrote that code originally. I feel alot
> better WITH the tests in place :-)
>
> And if it's merely to make sure the install worked, man who
> is doing source installations these days and runs the
> regression tests anyway? M
Bruce Momjian wrote:
> Jan Wieck wrote:
> > Bruce Momjian wrote:
> > > Well, our regression tests are not intended to test every possible
> > > NUMERIC combination, just a resonable subset. As it is now, I often
> > > think the regression tests have hung because numeric takes so much
> > > longer
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 12, 2002 2:38 PM
To: Tom Lane
Cc: Neil Conway; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [HACKERS] 7.3 schedule
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Oh, are you thinki
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Oh, are you thinking that one backend would do the PREPARE and another
> > one the EXECUTE? I can't see that working at all.
>
> Uh, why exactly were you advocating a shared cache then? Wouldn't that
> be exactly the *point* of a s
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Oh, are you thinking that one backend would do the PREPARE and another
> one the EXECUTE? I can't see that working at all.
Uh, why exactly were you advocating a shared cache then? Wouldn't that
be exactly the *point* of a shared cache?
Jan Wieck wrote:
> Bruce Momjian wrote:
> > Well, our regression tests are not intended to test every possible
> > NUMERIC combination, just a resonable subset. As it is now, I often
> > think the regression tests have hung because numeric takes so much
> > longer than any of the other tests. We
Neil Conway wrote:
> On Fri, 12 Apr 2002 12:21:04 -0400 (EDT)
> "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> > Tom Lane wrote:
> > > A per-backend cache kept in local memory avoids all of these problems,
> > > and I have seen no numbers to make me think that a shared plan cache
> > > would achieve
On Fri, 12 Apr 2002 12:21:04 -0400 (EDT)
"Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > A per-backend cache kept in local memory avoids all of these problems,
> > and I have seen no numbers to make me think that a shared plan cache
> > would achieve significantly more performance
Bruce Momjian wrote:
> Well, our regression tests are not intended to test every possible
> NUMERIC combination, just a resonable subset. As it is now, I often
> think the regression tests have hung because numeric takes so much
> longer than any of the other tests. We have had this code in ther
pg_dumping a table having a primary key yields commands like
--
-- TOC Entry ID 2 (OID 139812)
--
-- Name: table1 Type: TABLE Owner: postgres
--
CREATE TABLE "table1" (
"column10" character varying(255) NOT NULL,
"column1" character varying(255) NOT NULL,
"column2" smalli
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Certainly a shared cache would be good for apps that connect to issue a
> single query frequently. In such cases, there would be no local cache
> to use.
We have enough other problems with the single-query-per-connection
scenario that I see no reason t
Barry Lind wrote:
> Oracle's implementation is a shared cache for all plans. This was
> introduced in Oracle 6 or 7 (I don't remember which anymore). The net
> effect was that in general there was a significant performance
> improvement with the shared cache. However poorly written apps can
Jan Wieck wrote:
> Bruce Momjian wrote:
> > Jan Wieck wrote:
> > >
> > > I missed some of the discussion, because I considered the
> > > 1,000 digits already beeing complete nonsense and dropped the
> > > thread. So could someone please enlighten me what the real
> > > reaso
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> All of these seem to have good precision/range arguments for using
>> numeric accumulators, or to be enough off the beaten track that it's
>> not worth much angst to optimize them.
> Well, they *are* on the beaten track for someone, just not you! ;)
Tom Lane wrote:
> Yes, that is the part that was my sticking point last time around.
> (1) Because shared memory cannot be extended on-the-fly, I think it is
> a very bad idea to put data structures in there without some well
> thought out way of predicting/limiting their size. (2) How the heck
Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> > * The patch allows store query-planns to shared memory and is
> > possible EXECUTE it at more backends (over same DB) and planns
> > are persistent across connetions. For this feature I create special
> > memory con
Thomas Lockhart wrote:
>> The other day there was a discussion around the fact that X''
>> will get converted into an integer constant... ... while SQL99
>> says that this syntax *should* be used to specify a "binary
>> string". It looks like the hex-to-integer magic actually occurs in
>>
Neil Conway wrote:
> I would suggest using it any time you're executing the same query
> plan a large number of times. In my experience, this is very common.
> There are already hooks for this in many client interfaces: e.g.
> PrepareableStatement in JDBC and $dbh->prepare() in Perl DBI.
I'm not
> Which ones are you concerned about? As of 7.2, the only ones that use
> numeric accumulators for non-numeric input types are
...
OK, I did imply that I've been wanting to ask this for some time. I
should have asked during the 7.1 era, when this was true for more cases.
:)
> All of these seem
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I've been wanting to ask: we have in a few cases moved aggregate
> calculations from small, fast data types to using numeric as the
> accumulator.
Which ones are you concerned about? As of 7.2, the only ones that use
numeric accumulators for non-nume
Karel Zak <[EMAIL PROTECTED]> writes:
> * The patch allows store query-planns to shared memory and is
> possible EXECUTE it at more backends (over same DB) and planns
> are persistent across connetions. For this feature I create special
> memory context subsystem (like curre
...
> Also, the numeric regression tests takes much longer than the other
> tests. I don't see why a test of that length is required, compared to
> the other tests. Probably time to pair it back a little.
The numeric types are inherently slow. You might look at what effect you
can achieve by re
Bruce Momjian wrote:
> Jan Wieck wrote:
> >
> > I missed some of the discussion, because I considered the
> > 1,000 digits already beeing complete nonsense and dropped the
> > thread. So could someone please enlighten me what the real
> > reason for increasing our precis
Please disregard my last message which was intended for
[EMAIL PROTECTED]
Jean-Michel POURE
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
While I like the optimisation, the SQL syntax seems pretty horrible.
Could it not be done without changing the syntax at all, except to
change slightly how one defines a column? Given something like
CREATE TABLE item_name (
item_id INT PRIMARY KEY,
On Fri, 2002-04-12 at 03:33, Christopher Kings-Lynne wrote:
> > Fine. I'll work on that basis. I'll prepare a full-blown patch which can
> > be applied Monday -unless anyone else is sitting on uncommitted changes
> > to the directory that they want me to wait for?
>
> Nothing important. Shall I
On Thu, 2002-04-11 at 22:48, Tom Lane wrote:
> Barry Lind <[EMAIL PROTECTED]> writes:
> > ...
> > Since we
> > don't currently provide any information to the user on the relative cost
> > of the parse, plan and execute phases, the end user is going to be
> > guessing IMHO.
>
> You can in fact
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 12 April 2002 03:54
> To: Bruce Momjian
> Cc: Hiroshi Inoue; Christopher Kings-Lynne;
> [EMAIL PROTECTED]
> Subject: Re: RFC: Restructuring pg_aggregate
>
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I thi
Jean-Michel POURE wrote:
>
> Dear all,
>
> Here are some issues:
>
> 3) KDE3 is marvelous
> I now use KDE3 which is a perfect environment. I tried writing some code in
> kDevelop. It seems possible to write code fast... Therefore I am still asking
> myself ***why***we should continue develop
> To my humble opinion, KDE needs a real database abstraction layer (like
> pgSchema) with a multi-vendor interface. The only solution today is Gnome
> libgda. Unfortunately, libgda is not well-written. A good
> abstraction layer
> needs inheritence (C++, not C) and XML to handle specfic features
On Fri, Apr 12, 2002 at 12:41:34AM -0400, Neil Conway wrote:
> On Fri, 12 Apr 2002 12:58:01 +0900
> "Hiroshi Inoue" <[EMAIL PROTECTED]> wrote:
> >
> > Just a confirmation.
> > Someone is working on PREPARE/EXECUTE ?
> > What about Karel's work ?
Right question :-)
> I am. My work is based on
Dear all,
Here are some issues:
1) PostgreSQL installer (wizard)
http://www.networksimplicity.com/openssh has released an OpenSSH minimal
Cygwin installer. They have had 300.000 tracked downloads so far. If true,
this numer is superior to Cygwin downloads itself.
The installer is incompatibl
55 matches
Mail list logo
