[HACKERS] IMMUTABLE break inlining simple SQL functions.
Hello I though, so simple SQL functions should be inlined everywhere. When I tested sample for recent discussion, I found so immutable flag breaks inlining. Is it bug? postgres=# create or replace function foo(a int) returns int as $$ select $1+1$$ language sql STRICT IMMUTABLE; CREATE FUNCTION Time: 2,723 ms postgres=# SELECT * FROM pg_stat_user_functions ; funcid | schemaname | funcname | calls | total_time | self_time ++--+---++--- 16450 | public | foo | 3 | 0 | 0 (1 row) postgres=# SELECT foo(10); foo - 11 (1 row) funcid | schemaname | funcname | calls | total_time | self_time ++--+---++--- 16450 | public | foo | 4 | 0 | 0 (1 row) postgres=# create or replace function foo(a int) returns int as $$ select $1+1$$ language sql STRICT; CREATE FUNCTION Time: 3,716 ms postgres=# SELECT foo(11); foo - 12 (1 row) Time: 1,611 ms postgres=# SELECT * FROM pg_stat_user_functions ; funcid | schemaname | funcname | calls | total_time | self_time ++--+---++--- 16450 | public | foo | 4 | 0 | 0 (1 row) regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
On Sat, Aug 1, 2009 at 7:27 AM, Dimitri Fontainedfonta...@hi-media.com wrote: Unless you want me to test for impact on planner choices (even if we already know it has impact on pg_statistic), I'd say it's ready for commiter. Great, thanks for the review. I think if stadistinct is getting populated that's sufficient in terms of testing; the problems caused by inaccurate ndistinct estimates have been discussed elsewhere. I see you've already marked this Ready for Committer, thanks. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mixed, named notation support
On Fri, Jul 31, 2009 at 8:46 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/7/31 Bernd Helmle maili...@oopsware.de:
--On Montag, Juli 27, 2009 15:24:12 +0200 Bernd Helmle
maili...@oopsware.de wrote:
Hi,
I sending a little bit modified version - I removed my forgotten
comment in gram.y
Thanks, i'll look on it asap.
Looks good now.
Here is a slightly edited reviewed patch version. I've edited the docs and
fixed some spelling errors in a few error messages. It seems the patch
mangled some source comments in namespace.c, i've rearranged them and tried
to explain the purpose of VerifyCandidateNamedNotation(). I'm continuing
reviewing this but can't get on it again until sunday.
Pavel, can you have a look at the docs part of this patch and watch out for
any gotchas?
I looked there and I thing it's very good. I have only one idea about
samples in docs. Mathematical function isn't too much readable. Maybe
some string concation or returning record should be more readable.
create or replace function foo(a varchar, b varchar, uppercase boolean =
false)
returns varchar as $$
select when uppercase then 'a=' || a ', b=' || b
else upper('a=' || a ', b=' || b) end;
$$ language sql immutable strict;
select foo('Hello','World');
select foo('Hello', World', true);
select foo('Hello' as a, 'World' as b);
select foo('Hello', 'World', true as uppercase);
select foo(true as uppercase, 'World' as b, 'Hello' as b);
or some similar
Thank You very much
Pavel
What's the current status of this patch? Is someone (either Pavel or
Bernd) planning to update it further, or should it be marked Ready for
Committer?
Thanks,
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
On Thu, Jul 30, 2009 at 1:18 PM, Pavel Stehulepavel.steh...@gmail.com wrote: 2009/7/30 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: 2009/7/30 Robert Haas robertmh...@gmail.com: On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote: Hmm. For what it's worth, I think Pavel makes a good point about the number of exponent digits -- a large chunk of the use case for numeric formatting would be fixed-width reporting. +1. If you aren't trying to get the format exactly so, it's not clear why you're bothering with to_char() at all. Maybe we should to support some modificator like Large - L or E Five (or more?) E's seems like a natural extension to me. However, that still leaves us with the question of what to do when the exponent doesn't fit in however many digits we'd like to print. Seems like the options are * print #'s * force the output wider * throw an error None of these are very nice, but the first two could cause problems that you don't find out until it's too late to fix. What about throwing an error? I thing, so Oracle raise error. But I don't thing, so it is necessary repeat all Oracle the behave - mainly when is maybe not too much practical. * print #s, and force the output wider has one disadvantage - it cannot put clean signal about data problem in development time, maybe we should to add raise warning. * throw an error should to break bad written application in production, when is too late too. So anybody should have not complete test data set and there are a problem. I prefer print # with raising an warning. It seems like the discussion here has kind of died. We need to settle on an approach and get a final patch soon, or else defer this until next CommitFest. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mixed, named notation support
2009/8/2 Robert Haas robertmh...@gmail.com:
On Fri, Jul 31, 2009 at 8:46 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/7/31 Bernd Helmle maili...@oopsware.de:
--On Montag, Juli 27, 2009 15:24:12 +0200 Bernd Helmle
maili...@oopsware.de wrote:
Hi,
I sending a little bit modified version - I removed my forgotten
comment in gram.y
Thanks, i'll look on it asap.
Looks good now.
Here is a slightly edited reviewed patch version. I've edited the docs and
fixed some spelling errors in a few error messages. It seems the patch
mangled some source comments in namespace.c, i've rearranged them and tried
to explain the purpose of VerifyCandidateNamedNotation(). I'm continuing
reviewing this but can't get on it again until sunday.
Pavel, can you have a look at the docs part of this patch and watch out for
any gotchas?
I looked there and I thing it's very good. I have only one idea about
samples in docs. Mathematical function isn't too much readable. Maybe
some string concation or returning record should be more readable.
create or replace function foo(a varchar, b varchar, uppercase boolean =
false)
returns varchar as $$
select when uppercase then 'a=' || a ', b=' || b
else upper('a=' || a ', b=' || b) end;
$$ language sql immutable strict;
select foo('Hello','World');
select foo('Hello', World', true);
select foo('Hello' as a, 'World' as b);
select foo('Hello', 'World', true as uppercase);
select foo(true as uppercase, 'World' as b, 'Hello' as b);
or some similar
Thank You very much
Pavel
What's the current status of this patch? Is someone (either Pavel or
Bernd) planning to update it further, or should it be marked Ready for
Committer?
Hello
Bernard wrote so will look on it today - I expect so there will be
only cosmetic changes in doc.
Pavel
Thanks,
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/8/2 Robert Haas robertmh...@gmail.com: On Thu, Jul 30, 2009 at 1:18 PM, Pavel Stehulepavel.steh...@gmail.com wrote: 2009/7/30 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: 2009/7/30 Robert Haas robertmh...@gmail.com: On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote: Hmm. For what it's worth, I think Pavel makes a good point about the number of exponent digits -- a large chunk of the use case for numeric formatting would be fixed-width reporting. +1. If you aren't trying to get the format exactly so, it's not clear why you're bothering with to_char() at all. Maybe we should to support some modificator like Large - L or E Five (or more?) E's seems like a natural extension to me. However, that still leaves us with the question of what to do when the exponent doesn't fit in however many digits we'd like to print. Seems like the options are * print #'s * force the output wider * throw an error None of these are very nice, but the first two could cause problems that you don't find out until it's too late to fix. What about throwing an error? I thing, so Oracle raise error. But I don't thing, so it is necessary repeat all Oracle the behave - mainly when is maybe not too much practical. * print #s, and force the output wider has one disadvantage - it cannot put clean signal about data problem in development time, maybe we should to add raise warning. * throw an error should to break bad written application in production, when is too late too. So anybody should have not complete test data set and there are a problem. I prefer print # with raising an warning. It seems like the discussion here has kind of died. We need to settle on an approach and get a final patch soon, or else defer this until next CommitFest. Tom, please, can you write your opinion on my last proposal - print ### with raise warning. regards Pavel ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
Hi Robert, Hi all,
On Thursday 30 July 2009 05:05:48 Robert Haas wrote:
OK, here's the updated version of my machine-readable explain output
patch. This needed heavy updating as a result of the changes that Tom
asked me to make to the explain options patch, and the further changes
he made himself. In addition to any regressions I may have introduced
during the rebasing process, there is one definite problem here: in
the previous version of this patch, explain (format xml) returned XML
data; now, it's back to text.
The reason for this regression is that Tom asked me to change
ExplainStmt to just carry a list of nodes and to do all the parsing in
ExplainQuery. Unfortunately, the TupleDesc is constructed by
ExplainResultDesc() which can't trivially be changed to take an
ExplainState, because UtilityTupleDescriptor() also wants to call it.
We could possibly fix this by a hack similar to the one we already
added to GetCommandLogLevel(), but I haven't done that here.
Hm. I think its cleaner to move the option parsing into its own function - its
3 places parsing options then and probably not going to get less.
I am not sure this is cleaner than including the parsed options in ExplainStm
though... (possibly in a separate struct to avoid changing copy/equal-funcs
everytime)
Some more comments on the (new) version of the patch:
- The regression tests are gone?
- Currently a value scan looks like »Values Scan on *VALUES*« What about
adding its alias at least in verbose mode? This currently is inconsistent with
other scans. Also he output columns of a VALUES scan are named column$N even
if names as specified like in AS foo(colname)
- why do xml/json contain no time units anymore? (e.g. Total Runtime).
Admittedly thats already inconsistent in the current text format...
- Code patterns like:
if (es-format == EXPLAIN_FORMAT_TEXT)
appendStringInfo(es-str, Total runtime: %.3f ms\n,
1000.0 * totaltime);
else if (es-format == EXPLAIN_FORMAT_XML)
appendStringInfo(es-str,
Total-Runtime%.3f/Total-Runtime\n,
1000.0 * totaltime);
else if (es-format == EXPLAIN_FORMAT_JSON)
appendStringInfo(es-str, ,\n\Total runtime\ :
%.3f,
1000.0 * totaltime);
or
if (es-format == EXPLAIN_FORMAT_TEXT)
appendStringInfo(es-str, for constraint %s,
conname);
else if (es-format == EXPLAIN_FORMAT_XML)
{
appendStringInfoString(es-str,
Constraint-Name);
escape_xml(es-str, conname);
appendStringInfoString(es-str,
/Constraint-Name\n);
}
else if (es-format == EXPLAIN_FORMAT_JSON)
{
appendStringInfo(es-str, \n
\Constraint Name\: );
escape_json(es-str, conname);
}
possibly could be simplified using ExplainPropertyText or a function accepting
a format string.
At least for the !EXPLAIN_FORMAT_TEXT this seems simple at multiple places in
ExplainOnePlan and report_triggers.
On Friday 31 July 2009 23:13:54 Robert Haas wrote:
On Sat, Jul 18, 2009 at 10:29 PM, Andres Freundand...@anarazel.de wrote:
One part where I find the code flow ugly is 'did_boilerplate' in
report_triggers/its callsites.
I can see why it is done that way, but its not exactly obvious to read
when you want to find out how the format looks.
Suggestions?
The only idea without building more xml/json infrastructure I have is using a
separate stringbuffer inside report_triggers - but thats not much nicer.
Thats all I could find right now...
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] IMMUTABLE break inlining simple SQL functions.
Pavel Stehule pavel.steh...@gmail.com writes: I though, so simple SQL functions should be inlined everywhere. When I tested sample for recent discussion, I found so immutable flag breaks inlining. Your example proves nothing of the sort, since you have forgotten to allow for immutable functions being folded to constants. Actually, AFAICS both of these cases end up being folded to a constant, but I think the processing path is different --- one will just be evaluated on sight, the other gets inlined and is then seen to be a constant expression: regression=# create or replace function foo(a int) returns int as $$ regression$# select $1+1$$ language sql STRICT IMMUTABLE; CREATE FUNCTION regression=# explain verbose select foo(12); QUERY PLAN -- Result (cost=0.00..0.01 rows=1 width=0) Output: 13 (2 rows) regression=# create or replace function foo(a int) returns int as $$ select $1+1$$ language sql STRICT ; CREATE FUNCTION regression=# explain verbose select foo(12); QUERY PLAN -- Result (cost=0.00..0.01 rows=1 width=0) Output: 13 (2 rows) The fact that it gets inlined rather than evaluated per se is probably why the stats counter isn't affected. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Pavel Stehule pavel.steh...@gmail.com writes: Tom, please, can you write your opinion on my last proposal - print ### with raise warning. The idea of printing a warning seems completely horrid to me. From a logical point of view, either we think it's an error or we don't. From a practical point of view, warnings usually accomplish little except to bloat log files that a human might or might not ever look at. The real bottom line for to_char issues is almost always that we should do what Oracle does. Has anyone checked this behavior on Oracle? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
There wasn't any response to this comment: marcin mank marcin.m...@gmail.com writes: ALTER COLUMN SET DISTINCT feels like adding a unique constraint. ALTER COLUMN SET STATISTICS DISTINCT ? ALTER COLUMN SET STATISTICS NDISTINCT ? I don't want to add a new keyword, but SET STATISTICS DISTINCT would be an easy change. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
2009/8/2 Tom Lane t...@sss.pgh.pa.us: There wasn't any response to this comment: marcin mank marcin.m...@gmail.com writes: ALTER COLUMN SET DISTINCT feels like adding a unique constraint. ALTER COLUMN SET STATISTICS DISTINCT ? ALTER COLUMN SET STATISTICS NDISTINCT ? I don't want to add a new keyword, but SET STATISTICS DISTINCT would be an easy change. Comments? It's much better than SET DISTINCT. Pavel regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Prefix support for synonym dictionary
Hi,
The patch looks good.
Comments:
1. The docs should be clarified a little. For instance, it should have a
link back to the definition of a prefix search (12.3.2). I included my
doc suggestions as an attachment.
2. dsynonym_init() uses findwrd() in a slightly confusing (and perhaps
fragile) way. After calling findwrd(), the end pointer is pointing at
either the end of the string, or the *; depending on whether the string
ends in * and whether flags is NULL. I only mention this because I had
to take a more careful look to see what was happening. Perhaps add a
comment to make it more clear?
3. The patch looks for the special byte '*'. I think that's fine,
because we depend on the files being in UTF-8 encoding, where it's the
same byte. However, I thought it was worth mentioning in case we want to
support other encodings for text search files later.
Regards,
Jeff Davis
*** textsearch.sgml 2009-08-02 11:22:38.0 -0700
--- textsearch.sgml.new 2009-08-02 11:22:27.0 -0700
***
*** 2290,2315
/para
para
! Star sign literal*/literal at the end of definition word indicates,
! that definition word is a prefix and functionto_tsquery()/function
! function will transform that definition to the prefix search format.
! Notice, it is ignored in functionto_tsvector()/function.
/para
programlisting
- cat $SHAREDIR/tsearch_data/synonym_sample.syn
- postgrespgsql
- postgresql pgsql
- postgre pgsql
- gogle googl
- indices index*
- cat $SHAREDIR/tsearch_data/synonym_sample.syn
postgrespgsql
postgresql pgsql
postgre pgsql
gogle googl
indices index*
=# create text search dictionary syn( template=synonym,synonyms='synonym_sample');
=# select ts_lexize('syn','indices');
ts_lexize
--- 2290,2317
/para
para
! An asterisk (literal*/literal) at the end of definition word indicates
! that definition word is a prefix, and functionto_tsquery()/function
! function will transform that definition to the prefix search format (see
! xref linkend=textsearch-parsing-queries).
! Notice that it is ignored in functionto_tsvector()/function.
/para
+para
+ Contents of filename$SHAREDIR/tsearch_data/synonym_sample.syn/:
+/para
programlisting
postgrespgsql
postgresql pgsql
postgre pgsql
gogle googl
indices index*
+ /programlisting
+para
+ Results:
+/para
+ programlisting
=# create text search dictionary syn( template=synonym,synonyms='synonym_sample');
=# select ts_lexize('syn','indices');
ts_lexize
***
*** 2324,2329
--- 2326,2338
'index':*
(1 row)
+
+ =# select 'indexes are very useful'::tsvector;
+ tsvector
+ -
+ 'are' 'indexes' 'useful' 'very'
+ (1 row)
+
=# select 'indexes are very useful'::tsvector @@ to_tsquery('tst','indices');
?column?
--
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] compiler warning
A little while ago, I saw a compiler warning creep in: In file included from gram.y:11202: scan.c: In function ‘yy_try_NUL_trans’: scan.c:15765: warning: unused variable ‘yyg’ I know there were some changes to minimum versions, but I think I have those versions (listed below). I don't know if others are seeing this warning or not. Regards, Jeff Davis $ gcc --version gcc (Debian 4.3.3-14) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ flex --version flex 2.5.35 $ bison --version bison (GNU Bison) 2.4.1 Written by Robert Corbett and Richard Stallman. Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] compiler warning
Jeff Davis pg...@j-davis.com writes: A little while ago, I saw a compiler warning creep in: In file included from gram.y:11202: scan.c: In function âyy_try_NUL_transâ: scan.c:15765: warning: unused variable âyygâ Yeah, this is a bogosity in the current release of flex. http://sourceforge.net/tracker/index.php?func=detailaid=2820457group_id=97492atid=618177 regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Tom Lane escreveu: The real bottom line for to_char issues is almost always that we should do what Oracle does. Has anyone checked this behavior on Oracle? That was my point too. See [1]. [1] http://archives.postgresql.org/pgsql-hackers/2009-07/msg01870.php -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/8/2 Euler Taveira de Oliveira eu...@timbira.com: Tom Lane escreveu: The real bottom line for to_char issues is almost always that we should do what Oracle does. Has anyone checked this behavior on Oracle? That was my point too. See [1]. [1] http://archives.postgresql.org/pgsql-hackers/2009-07/msg01870.php so, Brendan, please, can you adjust patch to raise exception like Oracle? Thank You Pavel -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
On Sun, Aug 02, 2009 at 01:23:27PM -0400, Tom Lane wrote: There wasn't any response to this comment: marcin mank marcin.m...@gmail.com writes: ALTER COLUMN SET DISTINCT feels like adding a unique constraint. ALTER COLUMN SET STATISTICS DISTINCT ? ALTER COLUMN SET STATISTICS NDISTINCT ? I don't want to add a new keyword, but SET STATISTICS DISTINCT would be an easy change. Comments? +1 -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [HACKERS] revised hstore patch
On Wed, Jul 22, 2009 at 2:17 PM, Andrew Gierthand...@tao11.riddles.org.uk wrote: Unless I hear any objections I will proceed accordingly... At this point it's been 12 days since this was written and no updated patch has been posted, so I think it's well past time to move this to Returned with Feedback. Accordingly I'm going to make that change. Hopefully, an updated patch will be ready in time for the September CommitFest. Thanks, ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
On Sun, Aug 2, 2009 at 12:06 PM, Andres Freundand...@anarazel.de wrote:
Hi Robert, Hi all,
On Thursday 30 July 2009 05:05:48 Robert Haas wrote:
OK, here's the updated version of my machine-readable explain output
patch. This needed heavy updating as a result of the changes that Tom
asked me to make to the explain options patch, and the further changes
he made himself. In addition to any regressions I may have introduced
during the rebasing process, there is one definite problem here: in
the previous version of this patch, explain (format xml) returned XML
data; now, it's back to text.
The reason for this regression is that Tom asked me to change
ExplainStmt to just carry a list of nodes and to do all the parsing in
ExplainQuery. Unfortunately, the TupleDesc is constructed by
ExplainResultDesc() which can't trivially be changed to take an
ExplainState, because UtilityTupleDescriptor() also wants to call it.
We could possibly fix this by a hack similar to the one we already
added to GetCommandLogLevel(), but I haven't done that here.
Hm. I think its cleaner to move the option parsing into its own function - its
3 places parsing options then and probably not going to get less.
I am not sure this is cleaner than including the parsed options in ExplainStm
though... (possibly in a separate struct to avoid changing copy/equal-funcs
everytime)
Well, this is why we need Tom to weigh in.
Some more comments on the (new) version of the patch:
- The regression tests are gone?
Tom added some that look adequate to me to create_index.sql, as a
separate commit, so I don't think I need to do this in my patch any
more. Maybe some of those examples should be changed to output JSON
or XML, though, but I'd rather leave this up to Tom's discretion on
commit because I think he has opinions about this and I think my
chances of guessing what they are are low.
- Currently a value scan looks like »Values Scan on *VALUES*« What about
adding its alias at least in verbose mode? This currently is inconsistent with
other scans.
I don't know why this doesn't work, but I think it's unrelated to this patch.
Also he output columns of a VALUES scan are named column$N even
if names as specified like in AS foo(colname)
This is consistent with how other types of scans are treated.
rhaas=# explain verbose select x,y,z from (select * from pg_class) a(x,y,z);
QUERY PLAN
--
Seq Scan on pg_catalog.pg_class (cost=0.00..8.44 rows=244 width=72)
Output: pg_class.relname, pg_class.relnamespace, pg_class.reltype
(2 rows)
- why do xml/json contain no time units anymore? (e.g. Total Runtime).
Admittedly thats already inconsistent in the current text format...
I'm not sure what you mean by any more. I don't think any version
of these patches I ever submitted did otherwise, nor do I think it's
particularly valuable. Costs are implicitly in units of
PostgreSQL-costing and times are implicitly in units of milliseconds,
just as they are in the text format. Changing this would require
clients to strip off the trailing 'ms' before converting to a
floating-point number, which seems like an irritation with no
corresponding benefit.
- Code patterns like:
if (es-format == EXPLAIN_FORMAT_TEXT)
appendStringInfo(es-str, Total runtime: %.3f ms\n,
1000.0 * totaltime);
else if (es-format == EXPLAIN_FORMAT_XML)
appendStringInfo(es-str,
Total-Runtime%.3f/Total-Runtime\n,
1000.0 * totaltime);
else if (es-format == EXPLAIN_FORMAT_JSON)
appendStringInfo(es-str, ,\n \Total runtime\ :
%.3f,
1000.0 * totaltime);
or
if (es-format == EXPLAIN_FORMAT_TEXT)
appendStringInfo(es-str, for constraint
%s, conname);
else if (es-format == EXPLAIN_FORMAT_XML)
{
appendStringInfoString(es-str,
Constraint-Name);
escape_xml(es-str, conname);
appendStringInfoString(es-str,
/Constraint-Name\n);
}
else if (es-format == EXPLAIN_FORMAT_JSON)
{
appendStringInfo(es-str, \n
\Constraint Name\: );
escape_json(es-str, conname);
}
possibly could be simplified using ExplainPropertyText or a function accepting
a format string.
At least for the !EXPLAIN_FORMAT_TEXT this seems simple at multiple places in
ExplainOnePlan and
Re: [HACKERS] dependencies for generated header files
On Wed, Jul 29, 2009 at 9:28 AM, Robert Haasrobertmh...@gmail.com wrote: On Wed, Jul 29, 2009 at 8:43 AM, Peter Eisentrautpete...@gmx.net wrote: On Sunday 28 June 2009 21:21:35 Robert Haas wrote: I think that our dependencies for generated header files (gram.h, fmgroids.h, probes.h) are not as good as they could be. What we do right now is make src/backend/Makefile rebuild these before recursing through its subdirectories. This works OK for a top-level make, but if you run make further down in the tree (like under src/backend/commands) it won't necessarily rebuild everything that it should. The attached patch moves some of this logic from src/backend/Makefile to src/Makefile.global.in. Have you tried putting them in src/backend/common.mk? That might be a better place. No, I haven't. I can look at that at some point, but I'm a bit backed up right now. [ looks ] Is it conceivable that there might be a dependency on one of the generated header files from someplace in src other than src/backend? If so, it seems like that might be an argument for leaving it as I had it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] dependencies for generated header files
Robert Haas escribió: Is it conceivable that there might be a dependency on one of the generated header files from someplace in src other than src/backend? If so, it seems like that might be an argument for leaving it as I had it. Well, plperl.c includes fmgroids.h. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
Dimitri Fontaine dfonta...@hi-media.com writes:
Yes, and as I didn't have the time to install filterdiff I've attached
a revision of your patch in git format which adresses the problem I
mentioned, in a tarball also containing raw notes, tests, and
regression.{out,diffs}.
Applied with assorted corrections, plus the just-discussed change of
syntax to SET STATISTICS DISTINCT.
mqke check is failing on opr_sanity test in what looks like an
ordering issue, but I didn't feel confident enough to adapt the .out
to force the regression into passing.
Hmm, I saw no such change here, so I left the regression test alone.
It might be a platform-specific behavior, in which case the buildfarm
will soon tell us. If so, adding an ORDER BY to that query seems
like the right fix.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/8/3 Pavel Stehule pavel.steh...@gmail.com: 2009/8/2 Euler Taveira de Oliveira eu...@timbira.com: Tom Lane escreveu: The real bottom line for to_char issues is almost always that we should do what Oracle does. Has anyone checked this behavior on Oracle? That was my point too. See [1]. [1] http://archives.postgresql.org/pgsql-hackers/2009-07/msg01870.php so, Brendan, please, can you adjust patch to raise exception like Oracle? Well, the examples Euler posted in the linked message above were using E+308. If I'm reading the Oracle docs correctly, that would have triggered Oracle's data type overflow error before even getting to to_char(); Oracle's NUMBER type only supports up to E+126. So we still don't really know how Oracle handles a (legal) value with too many exponent digits for . Euler, could you post results for a number which fits within Oracle's data type but has three exponent digits (like 1E+100)? Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
Robert Haas robertmh...@gmail.com writes: On Sun, Aug 2, 2009 at 12:06 PM, Andres Freundand...@anarazel.de wrote: - Currently a value scan looks like »Values Scan on *VALUES*« What about adding its alias at least in verbose mode? This currently is inconsistent with other scans. I don't know why this doesn't work, but I think it's unrelated to this patch. If you mean something like regression=# explain select * from (values(1)) ss; QUERY PLAN - Values Scan on *VALUES* (cost=0.00..0.01 rows=1 width=4) (1 row) I think the reason is that the alias applies to a SubqueryScan node that later gets optimized away. The VALUES per se doesn't have an alias. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
On Sunday 02 August 2009 23:34:04 Robert Haas wrote:
On Sun, Aug 2, 2009 at 12:06 PM, Andres Freundand...@anarazel.de wrote:
Hi Robert, Hi all,
On Thursday 30 July 2009 05:05:48 Robert Haas wrote:
OK, here's the updated version of my machine-readable explain output
patch. This needed heavy updating as a result of the changes that Tom
asked me to make to the explain options patch, and the further changes
he made himself. In addition to any regressions I may have introduced
during the rebasing process, there is one definite problem here: in
the previous version of this patch, explain (format xml) returned XML
data; now, it's back to text.
The reason for this regression is that Tom asked me to change
ExplainStmt to just carry a list of nodes and to do all the parsing in
ExplainQuery. Unfortunately, the TupleDesc is constructed by
ExplainResultDesc() which can't trivially be changed to take an
ExplainState, because UtilityTupleDescriptor() also wants to call it.
We could possibly fix this by a hack similar to the one we already
added to GetCommandLogLevel(), but I haven't done that here.
Hm. I think its cleaner to move the option parsing into its own function
- its 3 places parsing options then and probably not going to get less. I
am not sure this is cleaner than including the parsed options in
ExplainStm though... (possibly in a separate struct to avoid changing
copy/equal-funcs everytime)
Well, this is why we need Tom to weigh in.
Yes.
Some more comments on the (new) version of the patch:
- The regression tests are gone?
Tom added some that look adequate to me to create_index.sql, as a
separate commit, so I don't think I need to do this in my patch any
more. Maybe some of those examples should be changed to output JSON
or XML, though, but I'd rather leave this up to Tom's discretion on
commit because I think he has opinions about this and I think my
chances of guessing what they are are low.
Yea, I was referring to ones using xml/json.
- Currently a value scan looks like »Values Scan on *VALUES*« What
about adding its alias at least in verbose mode? This currently is
inconsistent with other scans.
I don't know why this doesn't work, but I think it's unrelated to this
patch.
True.
Also he output columns of a VALUES scan are named column$N even
if names as specified like in AS foo(colname)
This is consistent with how other types of scans are treated.
rhaas=# explain verbose select x,y,z from (select * from pg_class)
a(x,y,z); QUERY PLAN
--
Seq Scan on pg_catalog.pg_class (cost=0.00..8.44 rows=244 width=72)
Output: pg_class.relname, pg_class.relnamespace, pg_class.reltype
(2 rows)
This is someone weird considering since using it directly in relations works
different:
explain (verbose) SELECT * FROM pg_namespace AS f(a,b,c);
QUERY PLAN
---
Seq Scan on pg_catalog.pg_namespace f (cost=0.00..1.06 rows=6 width=100)
Output: a, b, c
(2 rows)
Not your guilt though. Still its rather strange and looks worth fixable.
- why do xml/json contain no time units anymore? (e.g. Total Runtime).
Admittedly thats already inconsistent in the current text format...
I'm not sure what you mean by any more. I don't think any version
of these patches I ever submitted did otherwise, nor do I think it's
particularly valuable. Costs are implicitly in units of
PostgreSQL-costing and times are implicitly in units of milliseconds,
just as they are in the text format. Changing this would require
clients to strip off the trailing 'ms' before converting to a
floating-point number, which seems like an irritation with no
corresponding benefit.
I did not think any of your patches did - it was just a difference between the
original output and the new formats I just noted - as I said its not even
consistent in the text format.
- Code patterns like:
if (es-format == EXPLAIN_FORMAT_TEXT)
appendStringInfo(es-str, Total runtime: %.3f
ms\n, 1000.0 * totaltime); else if (es-format == EXPLAIN_FORMAT_XML)
appendStringInfo(es-str,
Total-Runtime%.3f/Total-Runtime\n, 1000.0 * totaltime); else if
(es-format == EXPLAIN_FORMAT_JSON)
appendStringInfo(es-str, ,\n\Total
runtime\ : %.3f, 1000.0 * totaltime); or
if (es-format == EXPLAIN_FORMAT_TEXT)
appendStringInfo(es-str, for constraint
%s, conname); else if (es-format == EXPLAIN_FORMAT_XML) {
appendStringInfoString(es-str,
Constraint-Name); escape_xml(es-str, conname);
[HACKERS] change in timestamp output from 8.3 to 8.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm testing pg_migrator, and running into an annoyance with timestamps while trying to verify the conversion. My steps were: install pg_migrator under 8.4 cluster run pg_migrator in copy mode -- pg_migrator reports success start up 8.4 cluster restore pg_control file in 8.3 cluster start 8.3 cluster run pg_dump from 8.4 against both 8.3 and 8.4 clusters compare the dump files diffs: 1. Two functions were left in the 8.4 database pg_toasttbl_drop(oid) pg_toasttbl_recreate(oid, oid) 2. Sequences had additional START WITH 1 3. All timestamps in the data that have two decimal places on seconds, but end with zero, in the 8.3 dump become one decimal place in the 8.4 dump The first two items are not much of an issue, but the third makes validation of the data very painful. I have to apologize for missing it if this has been discussed already, but was this change intentional, and if so is there any way to force the old behavior? Thanks, Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iQIcBAEBCAAGBQJKdieMAAoJEDfy90M199hlX5cP/iedAGnua275aR+GBj3M7psp x5ek93JMxs7U+MkWQ5ufcMbfhd5N+cRauZbnPAHoAa9yqdUanCubH+p2xqSlLOPn QISf/P11uJKnUOE2AuVUXVso2bBlp6WBpSxt5DgcpjsXgXWXNGmoVwRLb67+ZwX8 Hp7Kmi+OQewNfHwwkpybWvshx5N/BCrNfNfL/gqdEJTPG/H/7YjTomkKQIwdZDAt NhgSaNL/HcE9iISkkW1tlTNTZhCitow/6LIONQju5X6Un7aUWA8ke8AvWnobeieL xqzQbkwxa8Xhi4Yk61omupdXyYhJDHsOG1WUe4vlResmaYpeTzv3ztlhrfvBaJzv gom7B8xLmcwl3+znp0l78TDti2CcvgY5MThvTdymUFa0clYDf93bG8qHq90pw17P URA0QGLDnhCJThmV9nugw2dgpJCISR2pqsi9YYCX6zLa2dUw9IMWAfZMjyP4K3kP IzGUB8ppfRadOC5iavsoRdFwY6eClhU+jCTLlUkyN+KcmgJy5H1TwmrhBUEX0reW jkDZvnTs1+fx4S+yfJQYPpcpxsNp0a8RFAmzWPAF8p7uLNjZUsJtOC3rWNiUGdF8 o8PQPur8xBB5FebmZ0o1ig1ncW6SFREJ8+r1pz/w78fKjlADSy80tEGySPjGRLIL 2cpDvGcfJfR5UyVhB5n1 =6fOT -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
Robert Haas robertmh...@gmail.com writes: The reason for this regression is that Tom asked me to change ExplainStmt to just carry a list of nodes and to do all the parsing in ExplainQuery. Unfortunately, the TupleDesc is constructed by ExplainResultDesc() which can't trivially be changed to take an ExplainState, because UtilityTupleDescriptor() also wants to call it. We could possibly fix this by a hack similar to the one we already added to GetCommandLogLevel(), but I haven't done that here. I don't see anything particularly wrong with having ExplainResultDesc do the same kind of thing GetCommandLogLevel is doing. The alternative is to have it call a function that extracts all the parameters into an ExplainState, but the thing I have against that is that it makes for a larger cross-section of user mistakes that will result in throwing an elog() before we actually reach execution. I didn't want GetCommandLogLevel throwing any errors it doesn't actually have to, because that would interfere with logging of statements that could perfectly well get logged normally. I'm not sure if there are any comparable reasons to not want errors from UtilityTupleDescriptor, but there could well be. - The regression tests are gone? Tom added some that look adequate to me to create_index.sql, as a separate commit, so I don't think I need to do this in my patch any more. Maybe some of those examples should be changed to output JSON or XML, though, but I'd rather leave this up to Tom's discretion on commit because I think he has opinions about this and I think my chances of guessing what they are are low. Well, of course the existing tests are not going to exercise XML or JSON output format. Dunno how much we care. I had supposed that XML or JSON would always emit all the fields and leave it to the recipient to suppress what they don't want. If we want to have platform-independent regression tests then we'd need to make the COSTS option effective for XML/JSON format --- do we want that? I'm not sure what you mean by any more. I don't think any version of these patches I ever submitted did otherwise, nor do I think it's particularly valuable. Costs are implicitly in units of PostgreSQL-costing and times are implicitly in units of milliseconds, just as they are in the text format. Changing this would require clients to strip off the trailing 'ms' before converting to a floating-point number, which seems like an irritation with no corresponding benefit. I agree with not labeling these numbers. We definitely can't label the costs with anything useful, and labeling runtimes would be a bit inconsistent. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] change in timestamp output from 8.3 to 8.4
Joe Conway m...@joeconway.com writes: 1. Two functions were left in the 8.4 database pg_toasttbl_drop(oid) pg_toasttbl_recreate(oid, oid) This is pg_migrator's fault --- it should probably clean those up when it's done. 3. All timestamps in the data that have two decimal places on seconds, but end with zero, in the 8.3 dump become one decimal place in the 8.4 dump I have to apologize for missing it if this has been discussed already, but was this change intentional, and if so is there any way to force the old behavior? Yes, it was intentional. The discussion about changing it was around here: http://archives.postgresql.org/pgsql-hackers/2008-10/msg00394.php There's no exposed way to undo it, but you could probably revert the logic change in TrimTrailingZeros() until you'd convinced yourself things were okay. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
On Sun, Aug 2, 2009 at 6:17 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Dimitri Fontaine dfonta...@hi-media.com writes:
Yes, and as I didn't have the time to install filterdiff I've attached
a revision of your patch in git format which adresses the problem I
mentioned, in a tarball also containing raw notes, tests, and
regression.{out,diffs}.
Applied with assorted corrections, plus the just-discussed change of
syntax to SET STATISTICS DISTINCT.
Thanks. The changes all look good - except I'm curious why %g vs. %f?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
Robert Haas robertmh...@gmail.com writes: Thanks. The changes all look good - except I'm curious why %g vs. %f? So as not to add .00 unnecessarily. Positive values for ndistinct should be treated as integers. (I considered adding an error check to reject values like 20.5, but refrained...) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] change in timestamp output from 8.3 to 8.4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
1. Two functions were left in the 8.4 database
pg_toasttbl_drop(oid)
pg_toasttbl_recreate(oid, oid)
This is pg_migrator's fault --- it should probably clean those up
when it's done.
I figured as much. Not a big deal though...
3. All timestamps in the data that have two decimal places on seconds,
but end with zero, in the 8.3 dump become one decimal place in the
8.4 dump
I have to apologize for missing it if this has been discussed already,
but was this change intentional, and if so is there any way to force the
old behavior?
Yes, it was intentional. The discussion about changing it was
around here:
http://archives.postgresql.org/pgsql-hackers/2008-10/msg00394.php
There's no exposed way to undo it, but you could probably revert the
logic change in TrimTrailingZeros() until you'd convinced yourself
things were okay.
Ah, just the shortcut I was hoping for :-)
For the record, and anyone else trying to validate 8.3 to 8.4
migrations, the attached patch against 8.3.x makes it behave the same as
8.4.x. This reduced my version-to-version data diff to zilch.
Thanks!
Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iQIcBAEBCAAGBQJKdjGLAAoJEDfy90M199hlfOoP/3W+kXcvwzfVAxG/2rJWkKBP
ZRX0AG++kNDlzsMWCBSFfht2f3ERu0jnECKwnFb0+JF1EaWQJrPaGar1QqJ1IHZb
Iw9AjJE7LvwgcbC8mGmx1zTaI/DPwOvb+LvJIzUtXeoBLGyJuopvGWbcoOvZxvIX
dZkE97JOS0buTiUtUFedx/fpOv7ck/IRhlC4v83ghWl27mWwQ3K9U9S3kRSy3jB+
ajG0MQ3dSfK7usUgV8tfzdFkHQ8+L8PhehfBgRuqNGS1BQQvbNm7sOLnyjqB35w8
gWI37EZ6NMvVMS+880Y9+ktwpgVqVtAfzshtfzJq8HwtvWSiq6OF5wDhlxtwYLdW
h7xhvK37LoXutPMcf/HjflKoI1c9IhDj6CCwHyrxDRRjzfAvpJu7C+in9JrbvhvV
P1o5PpXuxokwafmNi6Nl8TE9s9Mjagw30tPKTK36IRfbAflbRpAByc39qvSXSRWB
xjzPYVHMY0Vwxmup+A7FXvdbzgC6t2n4O18302By0PKpPkMDZw3vhkJKgWF+i4Ux
no+GdL9Al3srpw4fvqr+GwPu8VnVFo+9fzCTlVMB2ayKWEFghCZUEriNBPJwiWaB
X9LtvrU47S5QkKUNQ0Knbs7Z1jEkIYIVnTIRvm6/Uo+5v2dAgss/0qF6wOx0gbUO
5EqsqcZzKhtkSjWxld7t
=eJkn
-END PGP SIGNATURE-
Index: src/backend/utils/adt/datetime.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/datetime.c,v
retrieving revision 1.184.2.3
diff -c -r1.184.2.3 datetime.c
*** src/backend/utils/adt/datetime.c 2 Oct 2008 13:47:44 - 1.184.2.3
--- src/backend/utils/adt/datetime.c 3 Aug 2009 00:26:53 -
***
*** 408,424
{
int len = strlen(str);
! #if 0
! /* chop off trailing one to cope with interval rounding */
! if (strcmp(str + len - 4, 0001) == 0)
! {
! len -= 4;
! *(str + len) = '\0';
! }
! #endif
!
! /* chop off trailing zeros... but leave at least 2 fractional digits */
! while (*(str + len - 1) == '0' *(str + len - 3) != '.')
{
len--;
*(str + len) = '\0';
--- 408,414
{
int len = strlen(str);
! while (len 1 *(str + len - 1) == '0' *(str + len - 2) != '.')
{
len--;
*(str + len) = '\0';
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
On Monday 03 August 2009 01:57:48 Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: - The regression tests are gone? Tom added some that look adequate to me to create_index.sql, as a separate commit, so I don't think I need to do this in my patch any more. Maybe some of those examples should be changed to output JSON or XML, though, but I'd rather leave this up to Tom's discretion on commit because I think he has opinions about this and I think my chances of guessing what they are are low. Well, of course the existing tests are not going to exercise XML or JSON output format. Dunno how much we care. I had supposed that XML or JSON would always emit all the fields and leave it to the recipient to suppress what they don't want. If we want to have platform-independent regression tests then we'd need to make the COSTS option effective for XML/JSON format --- do we want that? Options such as COSTS do effect XML/JSON right now. While not important for COSTS itself, I think its generally good to do so because a certain option might not be done per default efficiencywise and I don't see a reason to specialcase COSTS. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable explain output v4
On Sun, Aug 2, 2009 at 7:57 PM, Tom Lanet...@sss.pgh.pa.us wrote: Well, of course the existing tests are not going to exercise XML or JSON output format. Dunno how much we care. I had supposed that XML or JSON would always emit all the fields and leave it to the recipient to suppress what they don't want. If we want to have platform-independent regression tests then we'd need to make the COSTS option effective for XML/JSON format --- do we want that? Well, as I've said many, many times on these threads, I feel strongly that the choice of output format shouldn't for the most part affect the information which is displayed. Output format should be an option, and the information to display should be an option, and the two should be, as far as possible, separate. So what you're suggesting is the way it works now. http://archives.postgresql.org/pgsql-hackers/2009-05/msg00879.php http://archives.postgresql.org/pgsql-hackers/2009-05/msg00916.php http://archives.postgresql.org/pgsql-hackers/2009-05/msg00917.php http://archives.postgresql.org/pgsql-hackers/2009-05/msg00989.php ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
On Sun, Aug 2, 2009 at 8:35 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Thanks. The changes all look good - except I'm curious why %g vs. %f? So as not to add .00 unnecessarily. Positive values for ndistinct should be treated as integers. (I considered adding an error check to reject values like 20.5, but refrained...) Oh, I see. That makes sense. I think we do entirely too much forcing things to integers in the query planner as it is. The fact that a value can't truly be fractional doesn't mean that an estimate of the value can't be fractional. Now, in this particular case, it seems hard to imagine that 20.5 is a very useful value. But that's not really our problem: we just need to reject illegal values, not useless ones. I'm interested to see how useful this proves to be in the field. I implemented it mostly on a whim because you and others seemed to think it could have some value, and because I get an unhealthy amount of personal satisfaction out of writing code during my spare time. But the real test will be to see whether the real users who were getting bad query plans as a result of poor ndistinct estimates are able to make practical use of this feature to get better ones. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CommitFest Status Summary - 2009-08-03
We now have less than two weeks remaining in this CommitFest (assuming we stick with the usual time table of one month), and I would say we're in fairly good shape. There are less than a dozen patches left that are waiting on people other than the committers, or that are still under discussion. Here is again my best attempt to summarize which patches are waiting for which people; I've classed a handful of patches as Under Discussion, where it's not clear to me exactly who needs to take the next action for one reason or another. Anyone who is looking for a way to help is encouraged to read the threads related to the patches that are waiting on someone other than a committer, and chime in with thoughts or opinions. Several of the remaining patches are still in the queue not so much because they need review or rework, but because they lack either consensus or direction on what to do next. You don't need to be a coder to have an opinion on design. With respect to code reviewing, there is likely to be a need for some high-speed reviewing of Heikki's patches this week once Heikki has a chance to respond to feedback posted earlier in the CommitFest. I'm not sure it's going to be very realistic to get these into shape in the time that remains, but I guess we'll see (in some ways I feel that we've been somewhat unfair by not closing these out already; we've certainly given them more time than we would to a non-committer who was on vacation). We also need someone to review the rest of Greg Stark's merge append patch; Tom reviewed only the planner portions, and the assigned round-robin reviewer (Abhijit Menon-Sen) has not posted a review. ...Robert Specific Committer (11) == Revise parallel pg_restore's scheduling heuristic (Tom) Indexam API changes (Heikki, as patch author) Index-only quals (Heikki, as patch author) ECPG dynamic cursor, SQLDA support (Michael Meskes) ECPG support for string pseudo-type v2 (Michael Meskes) Determine client_encoding from client locale (Heikki, as patch author) async notifications for dblink (Joe Conway) query cancel issues in dblink (Joe Conway) Improvements for dict_xsyn extended synonym dictionary (Teodor) has_sequence_privilege() function (Joe Conway, awaiting feedback before commit) plpythonu datatype conversion improvements (Peter Eisentraut) Unspecified Committer (3) = GRANT ON ALL IN schema DefaultACLs multi-threaded pgbench Reviewer (3) Merge append (partially reviewed by Tom, needs new reviewer for rest of patch) new bytea hex output format Filtering dictionary support and unaccent dictionary Author (4) == machine-readable explain output v4 autogenerating headers bki stuff (may need to be bumped) return query and dropped columns Prefix support for synonym dictionary Under Discussion (4) Named and mixed notation for PL Support for in to_char() Parser's hook based on FuncCall (needs wider input) dependencies for generated header files -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Brendan Jurd escreveu: Well, the examples Euler posted in the linked message above were using E+308. If I'm reading the Oracle docs correctly, that would have triggered Oracle's data type overflow error before even getting to to_char(); Oracle's NUMBER type only supports up to E+126. So we still don't really know how Oracle handles a (legal) value with too many exponent digits for . As I said in a prior e-mail, Oracle has a diferent overflow limit (-84 to 127). In PostgreSQL, the numeric datatype can have up to 1000 digits (ie 1e+999) and the double precision datatype can have up to 309 digits (ie 1e-307 or 1e+308). We should support up to 3 exponent digits so all of our native datatypes are covered by the to_char() function. Euler, could you post results for a number which fits within Oracle's data type but has three exponent digits (like 1E+100)? I don't access to an Oracle Server now but it works fine up to the 127 limit. And differently to what Pavel proposed, the number of E's is not related to the number of characters (at least not anymore). So I would like to see the being used if we have 2 or 3 exponent digits (that is the same behavior Oracle has). -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest Status Summary - 2009-08-03
Robert Haas robertmh...@gmail.com writes: Unspecified Committer (3) = GRANT ON ALL IN schema DefaultACLs multi-threaded pgbench Personally I was thinking of multi-threaded pgbench as being Tatsuo-san's to commit, since that's his code originally. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
Euler Taveira de Oliveira eu...@timbira.com writes: As I said in a prior e-mail, Oracle has a diferent overflow limit (-84 to 127). In PostgreSQL, the numeric datatype can have up to 1000 digits (ie 1e+999) and the double precision datatype can have up to 309 digits (ie 1e-307 or 1e+308). We should support up to 3 exponent digits so all of our native datatypes are covered by the to_char() function. Uh, no, we had better support more. The actual limit of the current numeric format is 1e+131072. As long as we consider that should emit as many exponent digits as needed, this isn't particularly critical. But it would be if we try to specify an exact number of output digits. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: to_char, support for EEEE format
2009/8/3 Euler Taveira de Oliveira eu...@timbira.com: Brendan Jurd escreveu: Euler, could you post results for a number which fits within Oracle's data type but has three exponent digits (like 1E+100)? I don't access to an Oracle Server now but it works fine up to the 127 limit. And differently to what Pavel proposed, the number of E's is not related to the number of characters (at least not anymore). So I would like to see the being used if we have 2 or 3 exponent digits (that is the same behavior Oracle has). Okay, so Oracle just forces the output wider to accomodate the exponent (i.e., you can't rely on it being fixed-width). I can adjust the patch to imitate this behaviour; should be able to post a new revision within 24 hours. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CommitFest Status Summary - 2009-08-03
On Sun, Aug 2, 2009 at 9:49 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Unspecified Committer (3) = GRANT ON ALL IN schema DefaultACLs multi-threaded pgbench Personally I was thinking of multi-threaded pgbench as being Tatsuo-san's to commit, since that's his code originally. Ah see well that's why I post these summaries... :-) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Revised signal multiplexer patch
Hi, On Sat, Aug 1, 2009 at 5:27 AM, Tom Lanet...@sss.pgh.pa.us wrote: Fujii Masao masao.fu...@gmail.com writes: I revised the patch according to the suggestion. Applied with some mostly-cosmetic editorial work. Thank you very much! Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
