Robert Haas writes:
>> I first tried just the compare_fuzzy_path_costs() change and really
>> couldn't measure any reliable difference. oprofile output for CVS HEAD
>> looks like
> Well, there's obviously something different between your case and
> mine, because in my query add_path was the #1 C
Hannu Krosing wrote:
Some of the functions, including some specified in the standard, produce
fragments. That's why we have the 'IS DOCUMENT' test.
But then you could use xmlfragments as the functions return type, no ?
Not in the case of xpath, no.
There is a very compl
Thanks for taking a look at it.
> I first tried just the compare_fuzzy_path_costs() change and really
> couldn't measure any reliable difference. oprofile output for CVS HEAD
> looks like
Well, there's obviously something different between your case and
mine, because in my query add_path was the
[ This patch is on the 2009-First commitfest list, but there was earlier
discussion to the effect that it might be a good idea to include in 8.4,
so I made some time to look at it. ]
Robert Haas writes:
> I've been doing some benchmarking and profiling on the PostgreSQL
> query analyzer, and it s
On Feb 26, 2009, at 7:03 PM, Andrew Dunstan wrote:
can you point me at any call in libxml2 which will evaluate an xpath
expression in the context of a nodeset instead of a document?
No, I can't. node-sets are XPath objects not xmlNode objects, so I
don't think it would be as simple as modify
After a lot of distractions, I've finished applying the planner fixes
that seem necessary in view of your report about poorer planning in 8.4
than 8.3. When you have a chance, it would be useful to do a thorough
test of CVS HEAD on your data and query mix --- are there any other
places where we ha
On Fri, 2009-02-27 at 16:37 -0500, Andrew Dunstan wrote:
>
> Hannu Krosing wrote:
> > On Thu, 2009-02-26 at 13:51 -0500, Robert Haas wrote:
> >
> >>> What I have proposed for 8.3 should not break a single case that currently
> >>> behaves usefully. If anyone has a counter-example please show it
On Fri, 2009-02-27 at 13:25 -0500, Tom Lane wrote:
> So apparently we need to rethink this, and derate the correlation effect
> somehow when there are constraints on non-first columns. I'm not
> entirely sure what the model ought to be. Thoughts?
This seems similar to the problem of estimating c
On Fri, Feb 27, 2009 at 5:06 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> executing: yum install libselinux gives "Package
>> libselinux-2.0.73-1.fc10.i386 already installed and latest version"
>
> Yeah, but have you got libselinux-devel? A general rule on Red Hat
> based systems is that comp
Tom Lane wrote:
Andrew Dunstan writes:
I'll do some tests to see what the cost of extra xml parsing might be.
The extra cost appears to be fairly negligible.
Uh, you didn't actually show a comparison of before and after?
What it looks like to me is that this approach is
Jaime Casanova writes:
> executing: yum install libselinux gives "Package
> libselinux-2.0.73-1.fc10.i386 already installed and latest version"
Yeah, but have you got libselinux-devel? A general rule on Red Hat
based systems is that compiling a program that depends on library
package foo will re
Andrew Dunstan writes:
>> I'll do some tests to see what the cost of extra xml parsing might be.
> The extra cost appears to be fairly negligible.
Uh, you didn't actually show a comparison of before and after?
What it looks like to me is that this approach is free or nearly so for
well-formed do
On Sat, Feb 14, 2009 at 12:46 AM, KaiGai Kohei wrote:
> Jaime Casanova wrote:
>>
>> i only have ubuntu at hand, and i can install selinux from
>> repositories... do you see any problem with that?
>> i'm creating the VM now... will test on weekend...
>
> Now I checked the repository of Ubuntu, howe
Andrew Dunstan wrote:
Tom Lane wrote:
Hmm, does this proposal require adding a test of well-formed-ness to
a code path that doesn't currently have one? If so, is that likely
to contribute any noticeable slowdown?
I can't offhand see an objection to this other than possible performance
impa
Hannu Krosing wrote:
On Thu, 2009-02-26 at 13:51 -0500, Robert Haas wrote:
What I have proposed for 8.3 should not break a single case that currently
behaves usefully. If anyone has a counter-example please show it.
What I have proposed for 8.4 possibly would break current "useful" behavio
Tom Lane wrote:
> "Heikki Linnakangas" writes:
> > The trivial fix is to not call CacheInvalidateRelcache() in recovery
> > (patch attached). Another option is to put the check into
> > CacheInvalidateRelcache() itself, but in the name of consistency we
> > should then put the same check into t
On Thu, 2009-02-26 at 13:51 -0500, Robert Haas wrote:
> > What I have proposed for 8.3 should not break a single case that currently
> > behaves usefully. If anyone has a counter-example please show it.
> >
> > What I have proposed for 8.4 possibly would break current "useful" behaviour
> > (FSVO "
On Fri, 2009-02-27 at 12:21 -0800, Joshua D. Drake wrote:
> On Fri, 2009-02-27 at 22:17 +0200, Hannu Krosing wrote:
>
> > > Well VLDB is like 2% of what we need. If the above will remove all the
> > > B.S. currently associated with actually doing PITR (rsync, scp, nfs,
> > > pg_standby pick your p
On Fri, 2009-02-27 at 22:17 +0200, Hannu Krosing wrote:
> > Well VLDB is like 2% of what we need. If the above will remove all the
> > B.S. currently associated with actually doing PITR (rsync, scp, nfs,
> > pg_standby pick your poison) then I am all for it.
>
> If you use walmgr.py, then all you
On Tue, 2009-02-24 at 10:34 -0800, Joshua D. Drake wrote:
> On Tue, 2009-02-24 at 17:36 +, Simon Riggs wrote:
> > On Wed, 2009-02-25 at 00:51 +0900, Fujii Masao wrote:
> >
> > > On Tue, Feb 24, 2009 at 3:47 PM, K, Niranjan (NSN - IN/Bangalore)
> > > wrote:
> > > > Could you please let me know
I looked into Maxim Boguk's complaint here:
http://archives.postgresql.org/pgsql-general/2009-02/msg01226.php
in which the planner preferred to use an index despite the column
being searched on being a lower-order column in that index.
It turns out that the reason the planner is preferring the "wr
Heikki Linnakangas writes:
> Greg Stark wrote:
>> This isn't the first time we've run into the problem that we've run
>> out of signals. I think we need to multiplex all our event signals
>> onto a single signal and use some other mechanism to indicate the type
>> of message.
> Yeah. A patch to d
Peter Eisentraut writes:
> What should we do here, if anything? Redefine
> ERRCODE_INVALID_LIMIT_VALUE to the new SQL:2008 code?
If you're going to spell the errcode macros as suggested in the
patch, just remove ERRCODE_INVALID_LIMIT_VALUE.
Note that this patch misses at least two places where
Heikki Linnakangas wrote:
Zeugswetter Andreas OSB sIT wrote:
I did re-install Tune-Up Utilities, Kaspersky, Holdem Manager and
Daemon
Tools, so those were probably not the problemcause since it's still
working.
I think unfortunately it may be the case, that only initdb has a
problem.
Hmm
Zeugswetter Andreas OSB sIT wrote:
I did re-install Tune-Up Utilities, Kaspersky, Holdem Manager
and Daemon
Tools, so those were probably not the problemcause since it's
still working.
I think unfortunately it may be the case, that only initdb has a problem.
Hmm, wait a minute, initdb doesn'
Heikki Linnakangas wrote:
> As discussed at
> http://archives.postgresql.org/message-id/603c8f070902251956s16eee4a7l495d75d3ddccc...@mail.gmail.com,
>
> it's time to stop pushing hot standby into 8.4, take the time to work
> out the remaining details, and schedule it for 8.5. It will be a great
This is an updated and properly autoconf-guarded patch for this
previously reported issue:
"""
Jacek Drobiecki recently sent me a patch which stops postgresql to
actively violate the system limit of maximum open files
(RLIMIT_NOFILE) in src/backend/storage/file/fd.c, function
count_usable_fds().
Greg Stark wrote:
This isn't the first time we've run into the problem that we've run
out of signals. I think we need to multiplex all our event signals
onto a single signal and use some other mechanism to indicate the type
of message.
Yeah. A patch to do that was discussed a while ago, as Fuji
I was looking into adding new specific SQL:2008 error codes for invalid
LIMIT and OFFSET values (see attached patch), when I came across an
existing error code definition:
#define ERRCODE_INVALID_LIMIT_VALUE MAKE_SQLSTATE('2','2', '0','2','0')
This definition has been in our sources since err
> > We should delayload this dll since it is only needed
> > for specific configuration. No need to install when it is not used.
>
> That would require building knowledge of DLL names into the code,
> which isn't practical as some projects have a habit of changing them
> regularly (e.g. gettext).
On Fri, Feb 27, 2009 at 9:52 AM, Heikki Linnakangas
wrote:
>
> 2. Use a signal other than SIGQUIT for immediate shutdown of child
> processes. We can't change the signal sent to postmaster for
> backwards-compatibility reasons, but the signal sent by postmaster to child
> processes we could change
As discussed at
http://archives.postgresql.org/message-id/603c8f070902251956s16eee4a7l495d75d3ddccc...@mail.gmail.com,
it's time to stop pushing hot standby into 8.4, take the time to work
out the remaining details, and schedule it for 8.5. It will be a great
feature when it's released, and in
> I did re-install Tune-Up Utilities, Kaspersky, Holdem Manager
> and Daemon
> Tools, so those were probably not the problemcause since it's
> still working.
I think unfortunately it may be the case, that only initdb has a problem.
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers
We're using SIGQUIT to signal immediate shutdown request. Upon receiving
SIGQUIT, postmaster in turn kills all the child processes with SIGQUIT
and exits.
This is a problem when child processes use system(3) to call other
programs. We use system(3) in two places: to execute archive_command and
On Fri, Feb 27, 2009 at 9:39 AM, Magnus Hagander wrote:
> Dave Page wrote:
>> On Fri, Feb 27, 2009 at 8:47 AM, Zeugswetter Andreas OSB sIT
>> wrote:
>>> We should delayload this dll since it is only needed
>>> for specific configuration. No need to install when it is not used.
>>
>> That would re
Dave Page wrote:
> On Fri, Feb 27, 2009 at 8:47 AM, Zeugswetter Andreas OSB sIT
> wrote:
>> We should delayload this dll since it is only needed
>> for specific configuration. No need to install when it is not used.
>
> That would require building knowledge of DLL names into the code,
> which isn
I did re-install Tune-Up Utilities, Kaspersky, Holdem Manager and Daemon
Tools, so those were probably not the problemcause since it's still working.
On Wed, Feb 25, 2009 at 4:37 PM, Magnus Hagander wrote:
> Frank Featherlight wrote:
> > 1) Uninstalled the following programs+program files folder:
On Fri, Feb 27, 2009 at 8:47 AM, Zeugswetter Andreas OSB sIT
wrote:
>
> We should delayload this dll since it is only needed
> for specific configuration. No need to install when it is not used.
That would require building knowledge of DLL names into the code,
which isn't practical as some projec
We should delayload this dll since it is only needed
for specific configuration. No need to install when it is not used.
Andreas
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Dann Corbit
> Sent: Friday, Februar
39 matches
Mail list logo
