Thank you, Kasahara-san.
I think this is already patched in cvs of message catalogs. Could you try
psql.po from
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgtranslation/messages/ja/psql.po
regards,
--
Shigehiro Honda
From: Tatsuhito Kasahara
Subject: [HACKERS] patch for ja.po
Date: Fri, 22
2009/5/23 Gevik Babakhani :
> Is there a historical reason why we have a "proargtypes" and a
> "proallargtypes"?
> It seems that "proallargtypes" is only set when out parameters exist.
> Could someone clarify this please?
proargtypes is used for fast simple searching function in
transformFunc sta
Hi,
On 05/22/2009 05:54 PM, Tom Lane wrote:
This sort of ties into the discussions we have periodically about
allowing EXPLAIN to output XML or some other more-machine-friendly
data format. The barrier for adding additional output fields would
be a lot lower in such a format.
So the best thing
Is there a historical reason why we have a "proargtypes" and a
"proallargtypes"?
It seems that "proallargtypes" is only set when out parameters exist.
Could someone clarify this please?
Regards,
Gevik.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
Attached patch fixes following sun studio compiler warning:
"tsquery_op.c", line 193: warning: syntax error: empty declaration
"tsquery_op.c", line 194: warning: syntax error: empty declaration
"tsquery_op.c", line 195: warning: syntax error: empty declaration
"tsquery_op.c", line 196: warning:
On 22 May 2009, at 16:17, Greg Smith wrote:
On Fri, 22 May 2009, Greg Sabino Mullane wrote:
The bump from 10 to 100 was supported by microbenchmarks that
suggested it
would be tolerable.
No, the 10 to 100 was supported by years of people working in the
field who
routinely did that ad
On Thu, May 21, 2009 at 6:45 PM, Tom Lane wrote:
> Sam Mason writes:
> > On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote:
> >> ALTER TABLE ... ADD COLUMN ... NULL;
> >>
> >> (nullable without a default value). This is because of NULL bitmap in
> >> tuples. And it's greatest featur
Attached patch cleanups hash index headers to allow compile hasham for
8.3 version. It helps to improve pg_migrator with capability to migrate
database with hash index without reindexing.
I discussed this patch year ago with Alvaro when we tried to cleanup
include bloating problem. It should reduc
On Fri, 22 May 2009, Greg Sabino Mullane wrote:
The bump from 10 to 100 was supported by microbenchmarks that suggested it
would be tolerable.
No, the 10 to 100 was supported by years of people working in the field who
routinely did that adjustment (and >100) and saw great gains.
No one is s
When I compile postgresql now I get following message:
"../../../src/include/access/reloptions.h", line 45: warning: integer
overflow detected: op "<<"
The problem is on the following lines
typedef enum relopt_kind
{
...
RELOPT_KIND_MAX = (1 << 31)
}
enum is int datatype and 1 << 31 ==
Hello
2009/5/21 Tom Lane :
> Steve Prentice writes:
>> This patch is intended to supplement Pavel's patch for named and mixed
>> notation support in 8.5. This patch makes it so a plpgsql function can
>> call another function with the same parameter names using the named
>> parameters notation.
>
On 5/22/09 2:36 PM, Tom Lane wrote:
and...@dunslane.net writes:
Wouldn't he just need to rerun the tests with default_stats_target set to
the old value? I presume he has actually done this already in order to
come to the conclusion he did about the cause of the regression.
Yeah, he did, so we
On Fri, May 22, 2009 2:41 pm, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>> No, the 10 to 100 was supported by years of people working in the
>> field who routinely did that adjustment (and >100) and saw great
>> gains. Also, as the one who originally started the push to 100, my
>> original g
"Greg Sabino Mullane" writes:
> No, the 10 to 100 was supported by years of people working in the
> field who routinely did that adjustment (and >100) and saw great
> gains. Also, as the one who originally started the push to 100, my
> original goal was to get it over the "magic 99" bump, at which
"Joshua D. Drake" writes:
> We probably need to test this to get some more data points.
Agreed --- DBT2 is just one data point. We shouldn't assume that it's
definitive.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
and...@dunslane.net writes:
> Wouldn't he just need to rerun the tests with default_stats_target set to
> the old value? I presume he has actually done this already in order to
> come to the conclusion he did about the cause of the regression.
Yeah, he did, so we know it's slower that way. But ex
> Greg Smith writes:
>> Yesterday Jignesh Shah presented his extensive benchmark results
>> comparing
>> 8.4-beta1 with 8.3.7 at PGCon:
>> http://blogs.sun.com/jkshah/entry/pgcon_2009_performance_comparison_of
>
>> While most cases were dead even or a modest improvement, his dbt-2
>> results
>> su
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
While most cases were dead even or a modest improvement, his dbt-2 results
suggest a 15-20% regression in 8.4. Changing the default_statistics_taget
to 100 was responsible for about 80% of that regression.
On Fri, 2009-05-22 at 13:35 -0400, Stephen Frost wrote:
> Greg,
> dbt-2 is for OLTP, not for DW. Greg Smith's comment was actually that
> we shouldn't penalize the OLTP crowd (by raising the value) for the
> benefit of the DW crowd (who need it higher than 100 anyway).
>
I appear to have comple
Greg Smith writes:
> Yesterday Jignesh Shah presented his extensive benchmark results comparing
> 8.4-beta1 with 8.3.7 at PGCon:
> http://blogs.sun.com/jkshah/entry/pgcon_2009_performance_comparison_of
> While most cases were dead even or a modest improvement, his dbt-2 results
> suggest a 15-
Greg,
* Greg Sabino Mullane (g...@turnstep.com) wrote:
> > While most cases were dead even or a modest improvement, his dbt-2 results
> > suggest a 15-20% regression in 8.4. Changing the default_statistics_taget
> > to 100 was responsible for about 80% of that regression.
> ...
> > The situation
On Fri, 2009-05-22 at 16:43 +, Greg Sabino Mullane wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > While most cases were dead even or a modest improvement, his dbt-2 results
> > suggest a 15-20% regression in 8.4. Changing the default_statistics_taget
> > to 100 was res
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> While most cases were dead even or a modest improvement, his dbt-2 results
> suggest a 15-20% regression in 8.4. Changing the default_statistics_taget
> to 100 was responsible for about 80% of that regression.
...
> The situation where the st
Yesterday Jignesh Shah presented his extensive benchmark results comparing
8.4-beta1 with 8.3.7 at PGCon:
http://blogs.sun.com/jkshah/entry/pgcon_2009_performance_comparison_of
While most cases were dead even or a modest improvement, his dbt-2 results
suggest a 15-20% regression in 8.4. Chang
On Fri, May 22, 2009 at 4:54 PM, Tom Lane wrote:
>
> It doesn't really seem useful enough to justify breaking client-side
> code that looks at EXPLAIN output.
Fwiw at least pgadmin I don't think would be confused by this. These
tool authors aren't enamoured of fragile assumptions and the
maintena
(quoting more than usual to provide context because this is such an old thread)
On Sat, Oct 4, 2008 at 11:22 PM, Tom Lane wrote:
> I've applied the latest version of the CTE patch. Congratulations on
> making that happen!
>
> There are still some loose ends that need to be considered, though.
>
Andres Freund writes:
> On 05/22/2009 03:42 PM, Heikki Linnakangas wrote:
>> Isn't the discarded count always equal to (# of rows in table - matched
>> tuples)? Seems pretty redundant to me.
> Not for EXISTS(), LIMIT and similar.
It doesn't really seem useful enough to justify breaking client-si
Tatsuhito Kasahara wrote:
> Hi.
>
> Here is a asmall patch which fixes "bin/psql/po/ja.po".
> Now, psql returns the incorrect number of rows through ja.po.
> (see following)
Thanks. Please submit to pgtranslation through pgfoundry -- see
http://babel.postgresql.org/
--
Alvaro Herrera
As we discussed at pgcon2009 there are some changes/fixes necessary in
information_schema.columns to allow correct work of applications and
services via OLEDB on Windows. Here are some:
1. data_type field contains types names that are not recognized by MS apps.
Code around: rename types on the fl
Josh Berkus wrote:
> On 5/21/09 6:44 PM, Alvaro Herrera wrote:
>> Josh Berkus wrote:
The patch adds the "AS" keyword to the plpgsql grammar and doesn't
assign an expression parameter to the sql construct if the scalar
follows the AS keyword.
>>> Would it be possible to also support "
On 5/21/09 6:44 PM, Alvaro Herrera wrote:
Josh Berkus wrote:
The patch adds the "AS" keyword to the plpgsql grammar and doesn't
assign an expression parameter to the sql construct if the scalar
follows the AS keyword.
Would it be possible to also support "=" as well as "as"? I believe
that SQL
quot;1 rows"
best regards,
--
Tatsuhito Kasahara
kasahara.tatsuh...@oss.ntt.co.jp
diff -cpr Postgresql-CVS-20090522/src/bin/psql/po/ja.po
ja_po_fix/src/bin/psql/po/ja.po
*** Postgresql-CVS-20090522/src/bin/psql/po/ja.po 2009-05-22
18:01:22.0 +0900
--- ja_po_fix/src/bin/psql/po/ja.
Hi,
On 05/22/2009 03:42 PM, Heikki Linnakangas wrote:
Andres Freund wrote:
When analyzing the plan of a query I often find myself questioning
whether an additional index may be sensible, or if it is sensible that
a SeqScan is used if an index is available.
The current EXPLAIN ANALYZE only show
Andres Freund wrote:
When analyzing the plan of a query I often find myself questioning
whether an additional index may be sensible, or if it is sensible that a
SeqScan is used if an index is available.
The current EXPLAIN ANALYZE only shows the number of tuples matching the
qualifier of an
...
>From 4865950d8bb66ee29cead3ecb17b07812677bfdf Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Fri, 22 May 2009 15:37:13 +0200
Subject: [PATCH] Feature: discarded tuple count display in EXPLAIN ANALYZE
---
src/backend/commands/explain.c|5 +++--
src/backend/executor/execScan.c
Hi,
When analyzing the plan of a query I often find myself questioning
whether an additional index may be sensible, or if it is sensible that a
SeqScan is used if an index is available.
The current EXPLAIN ANALYZE only shows the number of tuples matching the
qualifier of an SeqScan Node - fo
please, please, please
David Fetter wrote:
On Fri, May 22, 2009 at 10:39:13AM +0200, Gevik Babakhani wrote:
Hi,
For the ones who couldn't attend to "How to Get Your PostgreSQL
Patch Accepted", could someone please make a summary. (Tom? Bruce?)
Thank you.
Video will get posted pretty
On Fri, May 22, 2009 at 10:39:13AM +0200, Gevik Babakhani wrote:
> Hi,
>
> For the ones who couldn't attend to "How to Get Your PostgreSQL
> Patch Accepted", could someone please make a summary. (Tom? Bruce?)
> Thank you.
Video will get posted pretty soon after, and expect tweets, blog
posts, etc
On Thu, May 21, 2009 at 12:26:08PM -0400, Tom Lane wrote:
> I'd envision it
> as an extra column in pg_attribute, and it would work for any column(s).
> There's nothing to be gained by restricting it.
Yes, when I said "first" I meant the only thing that needs to be stored
is the first default valu
Hi,
For the ones who couldn't attend to "How to Get Your PostgreSQL Patch
Accepted", could someone please make a summary. (Tom? Bruce?)
Thank you.
Regards,
Gevik.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
40 matches
Mail list logo
