Nedyalko Borisov writes:
> In summary, we are making two suggestions:
> 1. Extend the optimizer to consider joins between child tables when
> hierarchies are joined together.
We already handle this for the case where the join is nestloop with
inner index scan, and I'm not convinced that there's
--On 26. Juni 2009 13:08:37 +0900 KaiGai Kohei wrote:
* Is the named large object (including fully qualified one) worth?
It will enables us to specify a largeobject with human readable
identifier string.
I don't understand the notion of this. Does this mean you can create a LO
with
Tom Lane wrote:
> How big is your BBU cache?
On this machine, I guess it is 512MB. (Possibly 1GB, but I'm having
trouble finding the right incantation to check it at the moment, so
I'm going by what the hardware tech remembers.)
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Fri, June 26, 2009 4:13 pm, Kevin Grittner wrote:
> By the way, the number of xlog files seemed to always go to two above
> 2x checkpoint_segments.
The docs say:
"There will always be at least one WAL segment file, and will normally not
be more than (2 + checkpoint_completion_target) * checkp
"Kevin Grittner" writes:
> Regarding the fact that even with the xlog files pre-populated, the
> smaller set of xlog files is faster: I'm only guessing, but I suspect
> the battery backed RAID controller is what's defeating conventional
> wisdom here. By writing to the same, relatively small, set
Tom Lane wrote:
> "Kevin Grittner" writes:
>> The checkpoint_segments seems dramatic enough to be real. I wonder
>> if the test is short enough that it never got around to re-using
>> any of them, so it was doing extra writes for the initial creation
>> during the test?
>
> That's exactly what
Hi all,
We are working with Aster for the summer and we would like to bounce some ideas
that we are having for some possible PostgreSQL extensions. In order to
describe our ideas we will use the following example:
create table msg(
msg_id int,
msg text );
create table receiver(
msg_id i
Tom Lane wrote:
What I'd suggest Kris do is temporarily disable the NLS option on that
build, so we can get at least some useful testing from the machine.
After a proposed configure fix has been installed, re-enable NLS, verify
configure fails as expected, *then* upgrade msgfmt.
I disabled NL
Tom Lane wrote:
I see buildfarm member "canary" (NetBSD 1.6) was recently resurrected,
but is failing to build HEAD, because msgfmt fails like this:
po/es.po:8039: keyword "msgid_plural" unknown
po/es.po:8036: missing `msgstr' section
po/es.po:8039: parse error
This indicates (1) canary needs a
On Fri, June 26, 2009 11:39 am, Tom Lane wrote:
> to...@tuxteam.de writes:
>> On Fri, Jun 26, 2009 at 05:03:11PM +0200, Dimitri Fontaine wrote:
>>> It's becoming somewhat tricky, but maybe the test to do for the
>>> optimisation to get used is n >= threshold && str[n-6] == 0x20, Ã la
>>> Boyer/Moor
to...@tuxteam.de writes:
> On Fri, Jun 26, 2009 at 05:03:11PM +0200, Dimitri Fontaine wrote:
>> It's becoming somewhat tricky, but maybe the test to do for the
>> optimisation to get used is n >= threshold && str[n-6] == 0x20, Ã la
>> Boyer/Moore?
> That's cute. What about comparing the last ali
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Jun 26, 2009 at 05:03:11PM +0200, Dimitri Fontaine wrote:
> Le 26 juin 09 à 14:47, Jeremy Kerr a écrit :
>> For the new function to be faster, we need to know that there are more
>> than 6 (on average, depending on alignment) trailing spaces.
>
Le 26 juin 09 à 14:47, Jeremy Kerr a écrit :
For the new function to be faster, we need to know that there are more
than 6 (on average, depending on alignment) trailing spaces.
It's becoming somewhat tricky, but maybe the test to do for the
optimisation to get used is n >= threshold && str[n-
"Andrew Dunstan" writes:
> On Fri, June 26, 2009 9:34 am, Tom Lane wrote:
>> I doubt it's worth trying to fix this before 8.4 release, but it
>> should get looked into eventually.
> yes ... but presumably we don't want canary upgraded until we fix this,
> unless we get some other test platform fo
On Fri, June 26, 2009 9:34 am, Tom Lane wrote:
> I see buildfarm member "canary" (NetBSD 1.6) was recently resurrected,
> but is failing to build HEAD, because msgfmt fails like this:
>
> po/es.po:8039: keyword "msgid_plural" unknown
> po/es.po:8036: missing `msgstr' section
> po/es.po:8039: parse
On Friday 26 June 2009 12:07:24 Tsutomu Yamada wrote:
> Proposal: More portable way to support 64bit platforms
>
> Short description:
>
> Current PostgreSQL implementation has some portability issues to
> support 64bit platforms: pointer calculations using long is not
> portable, for example on Win
On Thu, Jun 25, 2009 at 10:41 PM, Itagaki
Takahiro wrote:
> Hi,
>
> contrib/dblink seems to have no treatments for query cancels.
> It causes the following issues:
>
> (1) Users need to wait for completion of remote query.
> Requests for query cancel won't be delivered to remote servers.
>
> (2)
Jeremy Kerr writes:
> Stephen,
>> If the updated function is always faster when the overall string is at
>> least, say, 16 characters long,
> But that's not the case - the cost of the function (and the speedup from
> the previous version) depends on the number of spaces that there are at
> the
I see buildfarm member "canary" (NetBSD 1.6) was recently resurrected,
but is failing to build HEAD, because msgfmt fails like this:
po/es.po:8039: keyword "msgid_plural" unknown
po/es.po:8036: missing `msgstr' section
po/es.po:8039: parse error
This indicates (1) canary needs a newer version of
Stephen,
> If the updated function is always faster when the overall string is at
> least, say, 16 characters long,
But that's not the case - the cost of the function (and the speedup from
the previous version) depends on the number of spaces that there are at
the end.
For the new function to
* Jeremy Kerr (j...@ozlabs.org) wrote:
> > Is it just the size that matters, or is it when there are few spaces
> > at the end?
>
> It's the number of spaces at the end. If we knew this number, then we
> wouldn't have to do any comparisons at all :)
I meant in terms of affecting the performance
Stephen,
> Is it just the size that matters, or is it when there are few spaces
> at the end?
It's the number of spaces at the end. If we knew this number, then we
wouldn't have to do any comparisons at all :)
Cheers,
Jeremy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
* Dimitri Fontaine (dfonta...@hi-media.com) wrote:
> Le 26 juin 09 à 05:20, Jeremy Kerr a écrit :
>>> Unfortunately, the cases with lots of padding spaces are probably
>>> much less probable than the cases with fewer. It would be unpleasant
>>> for example if this patch resulted in a severe perfor
Proposal: More portable way to support 64bit platforms
Short description:
Current PostgreSQL implementation has some portability issues to
support 64bit platforms: pointer calculations using long is not
portable, for example on Windows x64 platform. We propose to use
intptr_t instead of long, whi
Hi all,
following the link in
http://wiki.postgresql.org/wiki/Query_progress_indication
but mostly:
http://www.postech.ac.kr/~swhwang/progress2.pdf [1]
I'm trying to write an implementation of the "dne" method in postgresql.
I added another column to the pg_stat_get_activity function to repo
Hi,
Le 26 juin 09 à 05:20, Jeremy Kerr a écrit :
Unfortunately, the cases with lots of padding spaces are probably
much less probable than the cases with fewer. It would be unpleasant
for example if this patch resulted in a severe performance
degradation for a "canonical" example of char(n) bei
26 matches
Mail list logo
