Re: [HACKERS] gettext, plural form and translation
If the (n rows) is the *only* message that needs it then I think it would be simpler to just make it (Rows: n) instead. But I wouldn't be surprised if there were other messages with similar issues. -- greg -- 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] benchmarking the query planner
Robert Haas robertmh...@gmail.com wrote:
Works for me. Especially if you want to think more about ANALYZE before
changing that.
Well, it's something that would be sane to contemplate adding in 8.4.
It's way too late for any of this other stuff to happen in this release.
I'm thinking about trying to implement this, unless someone else is
already planning to do it. I'm not sure it's practical to think about
getting this into 8.4 at this point, but it's worth doing whether it
does or not.
Can we use get_relation_stats_hook on 8.4? The pg_statistic catalog
will be still modified by ANALYZEs, but we can rewrite the statistics
just before it is used.
your_relation_stats_hook(root, rte, attnum, vardata)
{
Call default implementation;
if (rte-relid = YourRelation attnum = YourColumn)
((Form_pg_statistic) (vardata-statsTuple))-stadistinct =
YourNDistinct;
}
Regards,
---
ITAGAKI Takahiro
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
Re: [HACKERS] gettext, plural form and translation
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Sergey Burladyan escribió: maybe build farm can help to test it ? Yes, I think we should implement it and see what happens with the buildfarm. If we stand still and do nothing, we won't be any wiser. The buildfarm is irrelevant to the fact that some platforms don't have ngettext. If the patch is designed to use ngettext where available, and to be no worse than what we have where it isn't, then we could consider it. It depends also on what we *want* to target. I originally omitted the plural support because it was a GNU extension, and I wanted to support standard gettext implementations as well. (There was also a licensing consideration.) Solaris is the original implementation of this API, so it can serve as a reference point. But it is open to debate whether that decision is more useful than the tradeoff it imposes. What I read now, however, is that Solaris 9 introduced the GNU-compatible ngettext extension, which changes the above argument considerably. Given the current information available to me, I would also be satisfied to require ngettext() and reject NLS support on platforms that don't provide it. -- 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] gettext, plural form and translation
Greg Stark wrote: If the (n rows) is the *only* message that needs it then I think it would be simpler to just make it (Rows: n) instead. But I wouldn't be surprised if there were other messages with similar issues. There are a few more, e.g., %d index pages have been deleted %d connections Identifier must be less than %d characters. -- 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] gettext, plural form and translation
Peter Eisentraut pete...@gmx.net writes: Greg Stark wrote: If the (n rows) is the *only* message that needs it then I think it would be simpler to just make it (Rows: n) instead. But I wouldn't be surprised if there were other messages with similar issues. There are a few more, e.g., %d index pages have been deleted %d connections Identifier must be less than %d characters. What's supposed to happen when a message contains more than one number (for example, most of the vacuum activity messages)? 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] gettext, plural form and translation
* Peter Eisentraut pete...@gmx.net [090319 04:21]:
It depends also on what we *want* to target. I originally omitted the
plural support because it was a GNU extension, and I wanted to support
standard gettext implementations as well. (There was also a licensing
consideration.) Solaris is the original implementation of this API,
so it can serve as a reference point.
But it is open to debate whether that decision is more useful than the
tradeoff it imposes.
Of course, ngettext can easily be ported, at it's most basic level
(equivalent to GNU's C locale implentation) it's:
#ifdef NEED_NGETTEXT
#define ngettext(s,p,n) gettext((n)==1?(s):(p))
#endif
Or a real port function:
const char* ngettext (const char*s, const char*p, int n)
{
return gettext(n == 1 ? s : p);
}
a.
--
Aidan Van Dyk Create like a god,
ai...@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
Re: [HACKERS] gettext, plural form and translation
Aidan Van Dyk wrote: * Peter Eisentraut pete...@gmx.net [090319 04:21]: It depends also on what we *want* to target. I originally omitted the plural support because it was a GNU extension, and I wanted to support standard gettext implementations as well. (There was also a licensing consideration.) Solaris is the original implementation of this API, so it can serve as a reference point. But it is open to debate whether that decision is more useful than the tradeoff it imposes. Of course, ngettext can easily be ported, at it's most basic level (equivalent to GNU's C locale implentation) it's: #ifdef NEED_NGETTEXT #define ngettext(s,p,n) gettext((n)==1?(s):(p)) #endif The more interesting question is whether such a msgfmt will correctly process message catalogs containing things like #: print.c:2351 #, c-format msgid (1 row) msgid_plural (%lu rows) msgstr[0] (1 Zeile) msgstr[1] (%lu Zeilen) My guess is not. -- 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] gettext, plural form and translation
Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: Greg Stark wrote: If the (n rows) is the *only* message that needs it then I think it would be simpler to just make it (Rows: n) instead. But I wouldn't be surprised if there were other messages with similar issues. There are a few more, e.g., %d index pages have been deleted %d connections Identifier must be less than %d characters. What's supposed to happen when a message contains more than one number (for example, most of the vacuum activity messages)? Heh. Good point. That is not supported. It would obviously explode the API. But I agree it's a problem. Btw., you can find out how much of a problem by using for x in $(find . -name *.pot); do msggrep -K -E -e '%[diu] [[:alpha:]].*%[diu] [[:alpha:]]' $x; done and manually hand-filtering the rest. I count about 16 problem messages. They are mostly vacuum messages as well as messages of the kind expected %d things but received only %d items. There are a number of additional messages that circumvent the problem by writing expected %d things but received only %d, but that is not possible in all cases. -- 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] Extension of Thick Indexes
Shrish, It's too late to get this into 8.4 at this point. Want to start a pgFoundry project around it, so people can play with it for 8.5? Also, for people not familiar with Gokul's work, can you give us an explanation of the theory and implementation for this? --Josh -- 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] hstore improvements?
Andrew, One request I've had is to construct a record (of some supplied composite type) from an hstore. I'm not sure if this is even possible; I'm certainly not seeing a way to implement it. Am I missing something? Well, presumably you'd try to match hstore tags against the columns of the composite type, and where a tag didn't exist, return NULL,and where one isn't in the composite type, ignore it. All data would be TEXT. --Josh -- 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] hstore improvements?
On 3/19/09 1:23 PM, Josh Berkus wrote: Andrew, One request I've had is to construct a record (of some supplied composite type) from an hstore. I'm not sure if this is even possible; I'm certainly not seeing a way to implement it. Am I missing something? Well, presumably you'd try to match hstore tags against the columns of the composite type, and where a tag didn't exist, return NULL,and where one isn't in the composite type, ignore it. All data would be TEXT. Oh, and in features I'd want, mostly an UNROLL for hstore ... that is, rather than a RECORD, a set of exploded rows. --Josh -- 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] Extension of Thick Indexes
Josh Berkus escribió: Also, for people not familiar with Gokul's work, can you give us an explanation of the theory and implementation for this? It would be helpful to explain how this solves the lack of atomicity of visibility data updates, which last time I checked was the killer problem for this feature. (It'd be good to do this in good ol' plain text email without resorting to compressed files on random text formats) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] pg_restore --multi-thread
On Thursday 12 February 2009 17:41:01 Peter Eisentraut wrote: I know we've already had a discussion on the naming of the pg_restore -m option, but in any case this description in pg_restore --help is confusing: -m, --multi-thread=NUM use this many parallel connections to restore Either it is using that many threads in the client, or it is using that many connections to the server. I assume the implementation does approximately both, but we should be clear about what we promise to the user. Either: Reserve this many connections on the server. Or: Reserve this many threads in the kernel of the client. The documentation in the reference/man page is equally confused. Also, the term multi is redundant, because whether it is multi or single is obviously determined by the value of NUM. After reviewing the discussion and the implementation, I would say workers would be the best description of the feature, but unfortunately the options -w or -W are not available. I'd also avoid -n or -N for num... because pg_dump already uses -n and -N for something else, and we are now trying to avoid inconsistent options between these programs. Also, option names usually don't start with units (imagine --num-shared-buffers or --num-port). While I think jobs isn't a totally accurate description, I would still propose to use -j/--jobs for the option name, because it is neutral about the implementation and has a strong precedent as being used to increase the parallelization to get the work done faster. I also noticed that Andrew D. used jobs in his own emails to comment on the feature. :-) The attached patch also updated the documentation to give some additional advice about which numbers to use. Index: doc/src/sgml/ref/pg_restore.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v retrieving revision 1.80 diff -u -3 -p -r1.80 pg_restore.sgml --- doc/src/sgml/ref/pg_restore.sgml 26 Feb 2009 16:02:37 - 1.80 +++ doc/src/sgml/ref/pg_restore.sgml 19 Mar 2009 21:18:32 - @@ -216,6 +216,46 @@ /varlistentry varlistentry + termoption-j replaceable class=parameternumber-of-jobs/replaceable/option/term + termoption--jobs=replaceable class=parameternumber-of-jobs/replaceable/option/term + listitem + para +Run the most time-consuming parts +of applicationpg_restore/ mdash; those which load data, +create indexes, or create constraints mdash; using multiple +concurrent jobs. This option can dramatically reduce the time +to restore a large database to a server running on a +multi-processor machine. + /para + + para +Each job is one process or one thread, depending on the +operating system, and uses a separate connection to the +server. + /para + + para +The optimal value for this option depends on the hardware +setup of the server, of the client, and of the network. +Factors include the number of CPU cores and the disk setup. A +good place to start is the number of CPU cores on the server, +but values larger than that can also lead to faster restore +times in many cases. Of course, values that are too high will +lead to decreasing performance because of thrashing. + /para + + para +Only the custom archive format is supported with this option. +The input file must be a regular file (not, for example, a +pipe). This option is ignored when emitting a script rather +than connecting directly to a database server. Also, multiple +jobs cannot be used together with the +option option--single-transaction/option. + /para + /listitem + /varlistentry + + varlistentry termoption-l/option/term termoption--list/option/term listitem @@ -242,28 +282,6 @@ /varlistentry varlistentry - termoption-m replaceable class=parameternumber-of-threads/replaceable/option/term - termoption--multi-thread=replaceable class=parameternumber-of-threads/replaceable/option/term - listitem - para -Run the most time-consuming parts of applicationpg_restore/ -mdash; those which load data, create indexes, or create -constraints mdash; using multiple concurrent connections to the -database. This option can dramatically reduce the time to restore a -large database to a server running on a multi-processor machine. - /para - - para -This option is ignored when emitting a script rather than connecting -directly to a database server. Multiple threads cannot be used -together with option--single-transaction/option. Also, the input -must be a plain file (not, for example, a pipe), and at present only -the custom archive format is supported. - /para -
Re: [HACKERS] pg_restore --multi-thread
Peter Eisentraut wrote: While I think jobs isn't a totally accurate description, I would still propose to use -j/--jobs for the option name, because it is neutral about the implementation and has a strong precedent as being used to increase the parallelization to get the work done faster. I also noticed that Andrew D. used jobs in his own emails to comment on the feature. :-) The attached patch also updated the documentation to give some additional advice about which numbers to use. Looks reasonable. cheers andrew -- 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] hstore improvements?
Hi, Le 19 mars 09 à 21:23, Josh Berkus a écrit : One request I've had is to construct a record (of some supplied composite type) from an hstore. I'm not sure if this is even possible; I'm certainly not seeing a way to implement it. Am I missing something? Well, presumably you'd try to match hstore tags against the columns of the composite type, and where a tag didn't exist, return NULL,and where one isn't in the composite type, ignore it. All data would be TEXT. The problem is more how to have the parser know which data type to target, because you want to avoid having to create a new cast per each composite type you want to target. A solution could maybe look like this: SELECT hstore_to_composite(hstore_value, null::my_composite_type); Regards, -- dim from the IRC-to-List bridge dept ;) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
