Ross J. Reedstrom wrote:
Hey Hackers -
I was testing beta5 and found a performance regression involving
application of constraints into a VIEW - I've got a view that is fairly
expensive, involving a subselet and an aggregate. When the query is
rewritten in 7.2.3, the toplevel constraint is used
Hey Hackers -
I was testing beta5 and found a performance regression involving
application of constraints into a VIEW - I've got a view that is fairly
expensive, involving a subselet and an aggregate. When the query is
rewritten in 7.2.3, the toplevel constraint is used to filter before
the subse
> pg_dump already has rudimentary dependency tracking (one level
> deep); each
> item can have a list of oid's it depends on. You *could* patch it to add
> the types to the table dependencies.
>
> In the future I'd imagine we'll just dump the OIDs of all first level
> dependencies for each object,
At 01:33 PM 13/11/2002 +0800, Christopher Kings-Lynne wrote:
Does this sound like an idea?
It does, but in keeping with allowing pg_restore to be quite flexible, I'd
like to see the dependency data stored in the dump file, then processed at
restore-time.
I've just become rather frustrated tr
Hi,
Has anyone given much thought to improving pg_dump's object order algorithm
for 7.4? It seems that now we have dependencies, it should just be a matter
of doing a breadth-first or depth-first search over the pg_depend table to
generate a valid order of oids.
To allow for mess-ups in that tab
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Thanks. I can commit it for 7.4. BTW, it would be nice if we could
> have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
> could see how PRPARE/EXECUTE could improve the performance...
That is a *must*. Otherwise, you've simply made an arb
Bravo Curtis,
This is all excellent research.
:-)
Regards and best wishes,
Justin Clift
Curtis Faith wrote:
> Disk space is much cheaper than CPU and memory so I think that a logging
> system that used as much as three or four times the space but is three or
> four times faster would be a wo
> > My concern is PREPARE/EXECUTE may NOT always improve the
> > performance. I guess we have very few data to judge PREPARE/EXECUTE is
> > good or not. Moreover PREPARE/EXECUTE might be improved in the
> > future. If that happens, keeping that switch would help examining the
> > effect, no?
>
> I
Tatsuo Ishii wrote:
> > > But one of the purposes of pgbench is examining performance on
> > > different environments, doesn't it? I'm afraid hard coded
> > > PREPARE/EXECUTE makes it harder.
> >
> > I was just thinking that pgbench is for measuring code changes, not for
> > testing changes _in_ p
> > But one of the purposes of pgbench is examining performance on
> > different environments, doesn't it? I'm afraid hard coded
> > PREPARE/EXECUTE makes it harder.
>
> I was just thinking that pgbench is for measuring code changes, not for
> testing changes _in_ pgbench. Once we know the perfor
Tatsuo Ishii wrote:
> > > Thanks. I can commit it for 7.4. BTW, it would be nice if we could
> > > have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
> > > could see how PRPARE/EXECUTE could improve the performance...
> >
> > We could probably just run before-after patch tests to s
> > Thanks. I can commit it for 7.4. BTW, it would be nice if we could
> > have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
> > could see how PRPARE/EXECUTE could improve the performance...
>
> We could probably just run before-after patch tests to see the
> performance change.
Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > What would be required to have OIDs for all SELECT/INTO product tables
> > for this release?
>
> It *might* work to just reverse the default assumption in
> ExecAssignResultTypeFromTL(). But I will vote against making such a
> cha
Tatsuo Ishii wrote:
> > Tatsuo, are you or anyone else working on adding PREPARE, EXECUTE support to
> > pgbench?
>
> As far as I know, no one is working on that.
>
> > If not, I can do it myself and if you are interested, I'll send you the
> > patch.
>
> Thanks. I can commit it for 7.4. BTW, it
> Tatsuo, are you or anyone else working on adding PREPARE, EXECUTE support to
> pgbench?
As far as I know, no one is working on that.
> If not, I can do it myself and if you are interested, I'll send you the
> patch.
Thanks. I can commit it for 7.4. BTW, it would be nice if we could
have a swit
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> Ok, now that I've run it that way, the last couple of pages of output
> look like this:
Hm. So the "while read line" loop is iterating only once.
I was thinking to myself that something within the while loop must be
eating up stdin, so that there's
On Tue, 12 Nov 2002, Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > OK, make -x check fails, is there some other way to use -x I'm not
> > thinking of here?
>
> I was thinking of running the script by hand, not via make:
>
> /bin/sh -x ./pg_regress --temp-install --top-buildd
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> OK, make -x check fails, is there some other way to use -x I'm not
> thinking of here?
I was thinking of running the script by hand, not via make:
/bin/sh -x ./pg_regress --temp-install --top-builddir=../../..
--schedule=./parallel_schedule --multib
On Tue, 12 Nov 2002, Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > And then it stops. Anyone know why it doesn't run the rest of the
> > regresssion tests?
>
> Somebody else just reported the same thing on Solaris. Must be
> something about the pg_regress script that does
On Tue, 12 Nov 2002, Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > And then it stops. Anyone know why it doesn't run the rest of the
> > regresssion tests?
>
> Somebody else just reported the same thing on Solaris. Must be
> something about the pg_regress script that does
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> And then it stops. Anyone know why it doesn't run the rest of the
> regresssion tests?
Somebody else just reported the same thing on Solaris. Must be
something about the pg_regress script that doesn't play nicely with
Solaris' shell. Can you poke
On 12 Nov 2002, Robert Treat wrote:
> On Tue, 2002-11-12 at 16:27, Tom Lane wrote:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > Bruce Momjian writes:
> > >> Are we ready for RC1 yet?
> >
> > > Questionable. We don't even have 50% confirmation coverage for the
> > > supported platforms
On 12 Nov 2002, Robert Treat wrote:
> On Tue, 2002-11-12 at 16:27, Tom Lane wrote:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > Bruce Momjian writes:
> > >> Are we ready for RC1 yet?
> >
> > > Questionable. We don't even have 50% confirmation coverage for the
> > > supported platforms
On Tue, 2002-11-12 at 16:27, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Bruce Momjian writes:
> >> Are we ready for RC1 yet?
>
> > Questionable. We don't even have 50% confirmation coverage for the
> > supported platforms yet.
>
> We can't just wait around indefinitely fo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> Are we ready for RC1 yet?
> Questionable. We don't even have 50% confirmation coverage for the
> supported platforms yet.
We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case,
Bruce Momjian writes:
> Are we ready for RC1 yet?
Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Use
Tom Lane wrote:
> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> > Ok, when #define NO_MKTIME_BEFORE_1970 is removed from aix.h, then the
> > results match the Solaris files.
>
> Great!
>
> > Attached is a patch to make AIX match Solaris. Please apply and add AIX
> > to the supported p
I have been doing some research about how to create new routines for
string collation and character case mapping that would allow us to break
out of the one-locale-per-process scheme. I have found that the Unicode
standard provides a lot of useful specifications and data for this. The
Unicode dat
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Ok, when #define NO_MKTIME_BEFORE_1970 is removed from aix.h, then the
> results match the Solaris files.
Great!
> Attached is a patch to make AIX match Solaris. Please apply and add AIX
> to the supported platforms.
Patch applied to 7.3
hi,
i think that ecpg is only text preprocessor. it doesn't understand the c
semantics - it goes from the top to the end of the file row by row and
sees your declaration twice.
kuba
On Tue, 12 Nov 2002, Marc G. Fournier wrote:
>
>
> if (ic_flag == 1) {
> /*only select those non-
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> Wouldn't it work for cntxDirty to be set not by LockBuffer, but by
>> XLogInsert for each buffer that is included in its argument list?
> I thought to add separate call to mark context dirty but above
> should work if all callers to XLogInsert always
Tatsuo, are you or anyone else working on adding PREPARE, EXECUTE support to
pgbench?
If not, I can do it myself and if you are interested, I'll send you the
patch.
- Curtis
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http
if (ic_flag == 1) {
/*only select those non-IC/Spyder nodes that has full update set*/
EXEC SQL DECLARE full_dyn_node CURSOR FOR
SELECT node_name FROM NODE
WHERE dynamic_community = 'f' AND ic_flag='n' AND machine_type!=22
> > I think so. The NO_MKTIME_BEFORE_1970 issue was bothering me, but I
> > feel that's resolved now. (It'd be nice to hear a crosscheck from
> > some AIX users though...)
>
> abstime, tinterval and horology fail on AIX.
> The rest is now working (AIX 4.3.2 xlc 5.0.0.2).
>
> I am just now rebu
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> Now, that's interesting. Why would defining a "numeric = float" have
> broken "numeric = integer"? There's no reason I can think of.
The problem probably is that the parser now finds two possible
interpretations that look equally good to it, so it ca
> I have removed the NO_MKTIME_BEFORE_1970 symbol from irix5.h,
> rebuilt 7.3b2, and reran the regression. The three time tests
> (tinterval, horology, abstime) now match the Solaris expected files.
> I checked the timezone files, and the system does not appear to
> have savings time d
Paul,
> "Unable to identify an operator '=' for types 'numeric' and 'double
> precision' You will have to retype this query using an explicit cast"
This is due, as you surmised, to decimal values defaulting to floats.
While there is little problem with an = operator for numeric and
float, you wo
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> abstime, tinterval and horology fail on AIX.=20
I would expect them now (without NO_MKTIME_BEFORE_1970) to match the
solaris-1947 comparison files for these tests. Could you confirm that?
regards, tom lane
---
Curtis, have you considered comparing raw writes versus file system writes
on a raw multi-disk partition?
I always set up my machines to store data on a mirror set (RAID1) or RAID5
set, and it seems your method should be tested there too.
P.s., Tom, the postgresql user would NOT need to run as
On Tue, 12 Nov 2002, Nicolas VERGER wrote:
> Scott you're right, it was a hardware problem.
> Thanks for your help.
>
Glad to be of help. What was the problem? Bad memory or bad hard drive?
Just curious.
---(end of broadcast)---
TIP 6: Have y
> > Are we ready for RC1 yet?
>
> I think so. The NO_MKTIME_BEFORE_1970 issue was bothering me, but I
> feel that's resolved now. (It'd be nice to hear a crosscheck from
> some AIX users though...)
abstime, tinterval and horology fail on AIX.
The rest is now working (AIX 4.3.2 xlc 5.0.0.2).
'K, looks like we need two things confirmed ... the change that Tom made
concerning mktime(), which we need someone on AIX to test ... and the
following ...
I've been following the commit messages closely, and haven't seen anything
go in that make me edgy, so if we can get validation on those two
tom lane wrote:
> What can you do *without* using a raw partition?
>
> I dislike that idea for two reasons: portability and security. The
> portability disadvantages are obvious. And in ordinary system setups
> Postgres would have to run as root in order to write on a raw partition.
>
> It occurs
Does any know the location of a good cvsup file for grabbing the
various releases?
There is none; when the configuration was changed the docs were not.
Use the appendix in the current docs (not whatever TODO is) and replace
the "pgsql" project name with "repository". Your CVS area will then
co
Hello,
Does any know the location of a good cvsup file for grabbing the
various releases?
The URL http://developer.postgresql.org/TODO/docs/cvsup.html is 404.
Thanks,
GB
P.S. Thanks to Tom, I found the perl stuff I needed.
P.P.S. The URL http://www.ca.postgresql.org/projects/index.html is ju
> Are we ready for RC1 yet?
I'm waiting for jenny wang confirms the fix regarding GB18030
support. In the mean time, I'll commit the fix anyway since current
GB183030 support is so badly broken (I have checked all regression
tests have passed).
--
Tatsuo Ishii
---(end of b
On Tue, 12 Nov 2002, Bruce Momjian wrote:
> Are we ready for RC1 yet?
This is Tuesday, you can only ask on Fridays :)
Vince.
--
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.
---(e
Tom Lane wrote:
"Pedro M. Ferreira" <[EMAIL PROTECTED]> writes:
[ patch for extra_float_digits ]
I've applied this patch along with followup changes to pg_dump (it sets
extra_float_digits to 2 to allow accurate dump/reload) and the geometry
regression test (it sets extra_float_digits to -3).
Scott you're right, it was a hardware problem.
Thanks for your help.
Nicolas VERGER
> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED]] De la part de scott.marlowe
> Envoyé : mercredi 6 novembre 2002 21:38
> À : Nicolas VERGER
> Cc : 'PostgreSQL Hack
49 matches
Mail list logo
