[EMAIL PROTECTED] writes:
> 7.4beta5 offers more throughput. One significant difference I see is in
> the oprofile for the database. For the additional 7% increase in the
> metric, there are about 32% less ticks in SearchCatCache.
Hmm. I have been profiling PG for some years now, and I cannot r
Neil Conway wrote:
> On Mon, 2003-10-27 at 15:31, Jan Wieck wrote:
> > Well, "partial solution" isn't quite what I would call it, and it surely
> > needs integration with sequential scans. I really do expect the whole
> > hack to fall apart if some concurrent seqscans are going on
>
> I'd rather
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> It appears we must not use the options for determining whether the test
> failed, only for creating the diff output. Or does anyone have a better
> idea?
AFAIK, there is no reason to ignore whitespace in determining whether a
test succeeded. However
Bruce Momjian writes:
> It is time for people to report their port testing. Please test against
> current CVS or beta5 and report your 'uname -a'.
This one is OK:
OpenBSD ob.credativ.de 3.4 GENERIC#65 sparc
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast
On OpenBSD 3.4, the diff options -b and -w have the interesting feature
(actually listed as a bug) that they ignore whitespace for preparing the
diff, but the exit status will be 1 nonetheless, if the files are at all
different. This leads to several failures in the current regression
tests, becau
Excellent.
I just noticed that most of the numbers in the system are given the
numeric data type. Is there any particular reason you don't use integer
(test enforced?)?
On Fri, 2003-10-31 at 19:18, [EMAIL PROTECTED] wrote:
> I thought someone might be interested in a data point I have comparing
>
- Original Message -
From: "Neil Conway" <[EMAIL PROTECTED]>
To: "Bruce Momjian" <[EMAIL PROTECTED]>
Cc: "Tatsuo Ishii" <[EMAIL PROTECTED]>; "Tom Lane" <[EMAIL PROTECTED]>;
"Joshua Drake" <[EMAIL PROTECTED]>; "PostgreSQL Hackers"
<[EMAIL PROTECTED]>
Sent: Friday, October 31, 2003 6:27 PM
I thought someone might be interested in a data point I have comparing
7.3.4 and 7.4beta5 with results from our DBT-2 workload. Keep in mind I
haven't done much tuning with either version. The following links have
references iostat, vmstat, sar, readprofile (linux kernel profile), and
oprofile (po
On Mon, 2003-10-27 at 15:31, Jan Wieck wrote:
> Well, "partial solution" isn't quite what I would call it, and it surely
> needs integration with sequential scans. I really do expect the whole
> hack to fall apart if some concurrent seqscans are going on
I'd rather see us implement a buffer repl
On Thu, 2003-10-30 at 23:13, Bruce Momjian wrote:
> If we do a short cycle, will we have enough features to justify a
> release? We could try to get PITR and Win32 done by January 1 and see
> if that can happen.
It's worth noting that we've thought about doing "quick" major releases
in the past,
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> nothing happens, because the revoke is implicitly assumed to mean
>> "revoke whatever privileges I granted", and Larry's superuser hasn't
>> granted any. The public privileges on language SQL were granted by
>> user postgres, and t
Tom Lane writes:
> nothing happens, because the revoke is implicitly assumed to mean
> "revoke whatever privileges I granted", and Larry's superuser hasn't
> granted any. The public privileges on language SQL were granted by
> user postgres, and they remain in force. So the later CREATE FUNCTION
Neil Conway <[EMAIL PROTECTED]> writes:
> Could someone who's aware of the bufmgr changes made for 7.2's lazy
> VACUUM comment on how this should be updated?
The only problem with it is that the future tense should be replaced by
the present tense ;-). Done --- thanks for noting the problem.
Tom Lane wrote:
"Stephen" <[EMAIL PROTECTED]> writes:
Great! I haven't tried it yet, but I love the thought of it already :-)
I've been waiting for something like this for the past 2 years and now it's
going to make my multi-gigabyte PostgreSQL more usable and responsive. Will
the delay be tuna
[EMAIL PROTECTED] ("scott.marlowe") writes:
> On Thu, 30 Oct 2003, Joshua D. Drake wrote:
>> If I understood correctly, Josh was complaining about VACUUM sucking too
>> >much of his disk bandwidth. autovacuum wouldn't help that --- in fact
>> >would likely make it worse, since a cron-driven vacuum
While reading through src/backend/storage/buffer/README, I noticed that
the following text seems to no longer be correct:
As of 7.1, the only operation that removes tuples or compacts
free space is (oldstyle) VACUUM. It does not have to implement
rule #5 directly, because
Bruce Momjian wrote:
What had me really confused was the first release item:
Allow polymorphic SQL functions (Joe)
How does an SQL function query the data types passed to it? Once I
saw that I thought I didn't underestand what polymorphic functions
were.
It doesn't need to. For example:
CREATE
--On Friday, October 31, 2003 16:49:17 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
*** ./expected/union.outThu Oct 9 20:49:31 2003
--- ./results/union.out Fri Oct 31 15:15:50 2003
***
*** 106,112
two
-
1.1
!2
(
Larry Rosenman <[EMAIL PROTECTED]> writes:
> *** ./expected/union.out Thu Oct 9 20:49:31 2003
> --- ./results/union.out Fri Oct 31 15:15:50 2003
> ***
> *** 106,112
>two
> -
>1.1
> !2
> (2 rows)
> SELECT 1.1 AS three UNION SELECT 2 UNION ALL SELEC
Bruce Momjian <[EMAIL PROTECTED]> writes:
> 7.4 pg_dump should be able to use 7.3's libpq --- the API has not
> changed, so we didn't bump the major number.
No, the other way 'round. 7.3 pg_dump or psql would work with a 7.4
libpq.so, but I don't believe 7.4 pg_dump or psql would work with a
7.3
Did we ever find the cause of this failure?
---
Rod Taylor wrote:
-- Start of PGP signed section.
> Linux ns2 2.4.20-xfs #2 Tue Apr 15 10:04:43 EDT 2003 i686 unknown
>
> <-- SNIP -->
> stats... FAILED
>
Here ya go:
test union... FAILED
test case ... ok
test join ... FAILED
*** ./expected/union.outThu Oct 9 20:49:31 2003
--- ./results/union.out Fri Oct 31 15:15:50 2003
***
*** 106,112
two
-
1.1
!2
(2 rows)
SELECT 1
Christopher Browne <[EMAIL PROTECTED]> writes:
> The advantage of the per-page delay is that performance is not being
> "totally hammered" by the vacuum. If things are so busy that it's an
> issue, the system is liable to "limp somewhat," but that's not as bad
> as what we see now, where VACUUM an
Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > > Is there any way we could build a static version of the 7.4 pg_dump, to
> > > make it easy to dump existing databases using the 7.4 dump? Otherwise,
> > > it's quite difficul
Joe Conway wrote:
> Bruce Momjian wrote:
> > http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-7-4
> >
> > I need people to check this and help me with the items marked 'bjm'. I
> > am confused about the proper text for those sections.
>
> > Allow polymorphic SQL functio
Kurt Roeckx wrote:
> On Thu, Oct 30, 2003 at 11:59:05PM -0500, Bruce Momjian wrote:
> >
> > OK, I have committed changes to release.sgml so most complex entries
> > have a paragraph describing the change. You can see the result at:
>
> * Full support for IPv6 connections and IPv6 address da
"Stephen" <[EMAIL PROTECTED]> writes:
> Great! I haven't tried it yet, but I love the thought of it already :-)
> I've been waiting for something like this for the past 2 years and now it's
> going to make my multi-gigabyte PostgreSQL more usable and responsive. Will
> the delay be tunable per VACU
On Thu, 2003-10-30 at 20:13, Jan Wieck wrote:
> Thanks for reporting, Michele.
Thank to you! The speed and level of your responses exceeds every my
more rose-colored expectation ;-)
> In the meantime, you might want to use a
> BEFORE INSERT trigger in PL/pgSQL that tries to UPDATE the row and i
Great! I haven't tried it yet, but I love the thought of it already :-)
I've been waiting for something like this for the past 2 years and now it's
going to make my multi-gigabyte PostgreSQL more usable and responsive. Will
the delay be tunable per VACUUM invocation? This is needed for different
ta
On Thu, 30 Oct 2003, Joshua D. Drake wrote:
> If I understood correctly, Josh was complaining about VACUUM sucking too
>
> >much of his disk bandwidth. autovacuum wouldn't help that --- in fact
> >would likely make it worse, since a cron-driven vacuum script can at
> >least be scheduled for low-
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Tom Lane wrote:
>> Best practice would likely be to leave the default vacuum_page_delay at
>> zero, and have the autovacuum daemon set a nonzero value for vacuums it
>> issues.
>
> What is the advantage of delaying vacuum per page vs. just doing vacuum
>
On Fri, 31 Oct 2003, Jan Wieck wrote:
> Stephan Szabo wrote:
> > On Thu, 30 Oct 2003, Tom Lane wrote:
> >
> >> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> > On Thu, 30 Oct 2003, Tom Lane wrote:
> >> >> rule/foreign key interaction reported by Michele Bendazzoli
> >>
> >> > In the interests of d
On Thu, Oct 30, 2003 at 11:59:05PM -0500, Bruce Momjian wrote:
>
> OK, I have committed changes to release.sgml so most complex entries
> have a paragraph describing the change. You can see the result at:
* Full support for IPv6 connections and IPv6 address data types
Prior releases
Bruce Momjian wrote:
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 2. I only bothered to insert delays in the processing loops of plain
>> VACUUM and btree index cleanup. VACUUM FULL and cleanup of non-btree
>> indexes aren't done yet.
>>
> I thought we d
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> This code completely ignores any other usage of the backslash in the
> escaped string, generating no output for unknown escape sequences. Is
> that the desired behaviour?
As Adam pointed out, the code does do the right thing for other
backslash
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What is the advantage of delaying vacuum per page vs. just doing vacuum
> less frequently?
The point is the amount of load VACUUM poses while it's running. If
your setup doesn't have a lot of disk bandwidth to spare, a background
VACUUM can hurt the per
Stephan Szabo wrote:
On Thu, 30 Oct 2003, Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Thu, 30 Oct 2003, Tom Lane wrote:
>> rule/foreign key interaction reported by Michele Bendazzoli
> In the interests of disclosure, if the case in question for the rule
> fails, almost certainly
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> * lib/autoconf/c.m4 (AC_C_INLINE): Test with a typedef return value,
> to avoid versions of HP C which don't allow that.
> So there you have it. Do we want to backpatch the new autoconf test, or
> define inline to empty for this parti
Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> 2. I only bothered to insert delays in the processing loops of plain
> >> VACUUM and btree index cleanup. VACUUM FULL and cleanup of non-btree
> >> indexes aren't done yet.
> >>
> > I thought we didn't wa
Tom Lane writes:
> Odd. I count ten inline functions in the backend:
> Why would only three of them fail?
I just remembered this Autoconf change:
2002-03-28 Kevin Ryde <[EMAIL PROTECTED]>
* lib/autoconf/c.m4 (AC_C_INLINE): Test with a typedef return value,
to avoid versions
Tom Lane <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Is there any way we could build a static version of the 7.4 pg_dump, to
> > make it easy to dump existing databases using the 7.4 dump? Otherwise,
> > it's quite difficult to arrange to have two diffe
Christopher Kings-Lynne wrote:
>
> > Does anyone have anything ready to put into CVS as soon as we start v7.5,
> > or shortly afterwards?
>
> Check bruce's 7.5 patches list (can't remember the address though :) )
>
> I have this COMMENT ON thing ready to go, except for this darn taking in
> uns
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > One other idea would be to set CFLAGS to "" before including template,
> > and just test to see if it is still "" after --- that might be cleaner
> > than saving the original value and comparing.
>
> Yeah, that bothered me a bit too -
Bruce Momjian <[EMAIL PROTECTED]> writes:
> It is time for people to report their port testing. Please test against
> current CVS or beta5 and report your 'uname -a'.
I can confirm CVS tip on HPUX 10.20, using both gcc and vendor's cc.
$ uname -a
HP-UX sss2 B.10.20 C 9000/780 2004473515 32-user
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> HP-UX hpunix5 B.11.00 U 9000/803 2002765023
> Using the system compiler, I get several complaints about our use of
> "inline", for example:
Interesting. CVS tip works fine for me on HPUX 10.20, using cc -Ae.
It looks like configure deduces inline is
Jan Wieck wrote:
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
See attached regression.diffs.
Looks like Jan forgot to update this expected file to match his changes.
regards, tom lane
Not exactly,
I didn't run the parallel regression test and thus missed that rules and
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Is there any way we could build a static version of the 7.4 pg_dump, to
> make it easy to dump existing databases using the 7.4 dump? Otherwise,
> it's quite difficult to arrange to have two different postgres
> installations, etc...
Why?
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
See attached regression.diffs.
Looks like Jan forgot to update this expected file to match his changes.
regards, tom lane
Not exactly,
I didn't run the parallel regression test and thus missed that rules and
foreign_key are i
Bruce Momjian writes:
> It is time for people to report their port testing. Please test against
> current CVS or beta5 and report your 'uname -a'.
For a change, here is one that does not work:
HP-UX hpunix5 B.11.00 U 9000/803 2002765023
Using the system compiler, I get several complaints about
49 matches
Mail list logo
