Hi all,
As AUTOVACUUM is having multiple workers now, the semantics of
autovacuum_cost_limit also need to be redefined.
Currently, autovacuum_cost_limit is the accumulated cost that will cause
one single worker vacuuming process to sleep. It is used to restrict
the I/O consumption of a single va
At Korea, Johab code is very old encondig.
by the way, cp949 code page is really used in most environments.
Personally speaking, Johab server code set is not need.
I think that PostgreSQL supports UHC (cp949) server code set.
This feature will be greet many Korean. :)
Unfortunately, UHC code set
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Backend encodings must have the property
>> that all bytes of a multibyte character are >= 128.
> But then, PG_JOHAB have already infringed it. Please see johab_to_utf8.map.
> Trailing bytes of JOHAB can be less
Tom Lane <[EMAIL PROTECTED]> wrote:
> > PostgreSQL suppots SJIS, BIG5, GBK, UHC and GB18030 as client encodings,
> > but we cannot use them as server encodings. Are there any reason for it?
>
> Very much so --- they aren't safe ASCII-supersets, and thus for example
> the parser will fail on them
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> PostgreSQL suppots SJIS, BIG5, GBK, UHC and GB18030 as client encodings,
> but we cannot use them as server encodings. Are there any reason for it?
Very much so --- they aren't safe ASCII-supersets, and thus for example
the parser will fail on them.
David Fetter <[EMAIL PROTECTED]> writes:
> I've written up a patch intended to implement this on the
> non-pg_catalog tables and VIEWs, but while it builds, it doesn't
> initdb. Enclosed are the patch and the error log.
> Any hints as to what I might look at?
> creating template1 database in
> /
Hello,
PostgreSQL suppots SJIS, BIG5, GBK, UHC and GB18030 as client encodings,
but we cannot use them as server encodings. Are there any reason for it?
AFAICS, we can support them only if we add each pg_xxx2wchar_with_len().
I'd like to add server-side SJIS supports for Windows Japanese edition.
I wrote:
> I'd like to take the TODO item that reads, "Add support for arrays of
> complex types," but before I start patching, I'd like to see whether
> what I'm about to do makes any sense:
I've written up a patch intended to implement this on the
non-pg_catalog tables and VIEWs, but while it b
Magnus Hagander <[EMAIL PROTECTED]> writes:
> tsearch2 regression tests are also failing on win32/msvc, with attached
> diffs.
> Any pointers on where to start? ;)
FWIW, it looks like it failed to reject stopwords. Is it possible you
ran it in an environment that would make it pick the Russian st
I wrote:
> I'd venture that we should try to get rid of the restriction, but I'm
> unsure whether removing the error check is sufficient or whether there
> are real problems it's preventing.
I did a little experimentation and it seems that DECLARE CURSOR,
FETCH, and CLOSE work perfectly fine when
I wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Again though, I really don't think it matters.
> Agreed, it's unlikely this would be a significant change either way.
Just for the record, pgbench numbers seem unaffected by this patch
(on Fedora Core 6 x86_64).
rega
"Tom Lane" <[EMAIL PROTECTED]> writes:
> What's your point?
Apparently my point is that I should have checked the docs before assuming I
understood how this variable worked. I guess I've never needed to touch it
before.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
-
Gregory Stark <[EMAIL PROTECTED]> writes:
> That's not really the point. The problem is that the compiler usually can't
> deduce which function you're calling or even which set of functions you might
> be calling. So, for example, the compiler will have trouble determining which
> variables may be
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> It sounds like a fine idea from the point of view of flexibility. But as far
>> as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
>> used in contexts where the compiler is able to opti
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, you're right. This arises from the fact that _SPI_execute_plan
>> rejects cursor-related utility statements. While I'd never stopped
>> to question that before, it does seem like this restriction is a
>> bit pointless. Does anyon
stark <[EMAIL PROTECTED]> writes:
> postgres=# show datestyle;
> DateStyle
> ---
> ISO, DMY
> (1 row)
> postgres=# set datestyle='DMY,ISO';
> SET
> postgres=# show datestyle;
> DateStyle
> ---
> ISO, DMY
> (1 row)
What's your point?
regards, tom lane
Ühel kenal päeval, R, 2007-03-23 kell 06:10, kirjutas Andrew -
Supernews:
> On 2007-03-23, ITAGAKI Takahiro <[EMAIL PROTECTED]> wrote:
> > Thanks, it all made sense to me. My proposal was completely wrong.
>
> Actually, I think your proposal is fundamentally correct, merely incomplete.
>
> Doing
Neil Conway <[EMAIL PROTECTED]> writes:
> Rather than removing the copyright clause per se, it might be better to
> just update to the latest versions of these files in an upstream source
> (e.g. NetBSD). They've already gone through their source tree and
> updated the Berkeley copyrights as app
Jim Nasby <[EMAIL PROTECTED]> writes:
> On Mar 21, 2007, at 5:11 AM, Tom Lane wrote:
>> constraint_exclusion
> Hrm... wasn't that option added in case there was a bug in the
> exclusion code?
Well, the "bug" was a lack of ways to get rid of plans that were
no longer valid because of constraint
Gregory Stark <[EMAIL PROTECTED]> writes:
> It sounds like a fine idea from the point of view of flexibility. But as far
> as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
> used in contexts where the compiler is able to optimize away the conditionals
> or the cpu is abl
On Sat, Mar 24, 2007 at 11:28:26PM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I have emailed Andrew Yu to see if we can remove his line, but I
> > question whether the other people can be reached.
> > How should we handle this?
> If they are released under the BSD license, why do we ca
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > >> I'm confused. If this is exactly the same as EUC_JP, why do we need
> > >> any new code at all?
> >
> > > I said *encoding schema" is same, not the contents (character set) is
> > > same. In another word, characters included in EUC_JP are not sa
"Martijn van Oosterhout" writes:
> On Sat, Mar 24, 2007 at 09:37:07PM +, Gregory Stark wrote:
>
>> It sounds like a fine idea from the point of view of flexibility. But as far
>> as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
>> used in contexts where the compile
On Sat, Mar 24, 2007 at 09:37:07PM +, Gregory Stark wrote:
> It sounds like a fine idea from the point of view of flexibility. But as far
> as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
> used in contexts where the compiler is able to optimize away the conditional
24 matches
Mail list logo
