Communauté francophone de PostgreSQL

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
<html>
<p><strong>Nouvelles hebdomadaires de PostgreSQL - 28 Mai 2007</strong></p>
<p>La semaine pass&eacute;e, les <i>PgCon</i> furent un brillant succ&egrave;s.</p>

<p><strong>Les nouveaut&eacute;s des produits d&eacute;riv&eacute;s</strong></p>
<p>Aucune annonce "commerciale" cette semaine.</p>
<p><strong>PostgreSQL Jobs for May</strong></p>
<p><a target="_blank" href="http://archives.postgresql.org/pgsql-jobs/2007-05/threads.php">http://archives.postgresql.org/pgsql-jobs/2007-05/threads.php</a></p>
<p><strong>PostgreSQL Local</strong></p>
<p>Les inscriptions pour les pgday.it du 6 et 7 juillet sont ouvertes. L'&eacute;v&eacute;nement aura lieu en Toscane, &agrave; Prato (Italie).</p>

<p>Quelques URLs &agrave; noter&nbsp;:</p>
<ul>
<li>Inscription&nbsp;: 
<a target="_blank" href="http://www.pgday.it/en/generale/registrazione">http://www.pgday.it/en/generale/registrazione</a></li>
<li>Site web d&eacute;di&eacute;&nbsp;: 
<a target="_blank" href="http://www.pgday.it/en/">http://www.pgday.it/en/</a></li>
<li>Sponsoriser l'&eacute;v&eacute;nement&nbsp;: 

<a target="_blank" href="http://www.pgday.it/en/sponsorizzazioni/come">http://www.pgday.it/en/sponsorizzazioni/come</a></li>
<li>...en commandant un T-shirt PostgreSQL ? 
<a target="_blank" href="http://www.prato.linux.it/node/30">http://www.prato.linux.it/node/30</a></li>
<li>Moyens de transport&nbsp;: 
<a target="_blank" href="http://www.pgday.it/en/logistica/raggiungere_prato">http://www.pgday.it/en/logistica/raggiungere_prato</a></li>
<li>H&eacute;bergement&nbsp;: 
<a target="_blank" href="http://www.pgday.it/en/logistica/dove_dormire">http://www.pgday.it/en/logistica/dove_dormire</a></li>
</ul>
<p>Dates importantes&nbsp;:</p>

<ul>
<li>31 Mai&nbsp;: date limite pour la remise des pr&eacute;sentations,</li>
<li>5 Juin&nbsp;: fin des tarifs avantageux offerts par les H&ocirc;tels San Marco et Art Hotel Milano.</li>
</ul>
<p><strong>PostgreSQL dans les m&eacute;dia</strong></p>
<ul>
<li>Planet PostgreSQL: 
<a target="_blank" href="http://www.planetpostgresql.org/%3C/li%3E">http://www.planetpostgresql.org/</a></li>

<li>General Bits, Archives et articles occasionnels: 
<a target="_blank" href="http://www.varlena.com/GeneralBits/%3C/li%3E">http://www.varlena.com/GeneralBits/</a></li>
</ul>
<p><i>Les PostgreSQL Weekly News vous sont pr&eacute;sent&eacute;es cette semaine par David Fetter. Adaptation francophone par la communaut&eacute; PostgresqlFr.</i></p>
<p><i>Vos propositions d'informations doivent parvenir avant dimanche minuit &agrave; david@fetter.org. Les propositions en allemand peuvent &ecirc;tre envoy&eacute;es &agrave; pwn@pgug.de.</i></p>

<p><strong>Applied Patches</strong></p>
<p>Alvaro Herrera a commit&eacute;&nbsp;:</p>
<ul>
<li>Pavel Stehule's patch which removes unsupported -u option from pg_standby example usage.</li>
</ul>
<p>Tom Lane a commit&eacute;&nbsp;:</p>
<ul>
<li>Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.</li>
<li>Repair two constraint-exclusion corner cases triggered by proving that an inheritance child of an UPDATE/DELETE target relation can be excluded by constraints. I had rearranged some code in set_append_rel_pathlist() to avoid "useless" work when a child is excluded, but overdid it and left the child with no cheapest_path entry, causing possible failure later if the appendrel was involved in a join. Also, it seems that the dummy plan generated by inheritance_planner() when all branches are excluded has to be a bit less dummy now than was required in 8.2. Per report from Jan Wieck. Add his test case to the regression tests.</li>

<li>Create hooks to let a loadable plugin monitor (or even replace) the planner and/or create plans for hypothetical situations; in particular, investigate plans that would be generated using hypothetical indexes. This is a heavily-rewritten version of the hooks proposed by Gurjeet Singh for his Index Advisor project. In this formulation, the index advisor can be entirely a loadable module instead of requiring a significant part to be in the core backend, and plans can be generated for hypothetical indexes without requiring the creation and rolling-back of system catalog entries. The index advisor patch as-submitted is not compatible with these hooks, but it needs significant work anyway due to other 8.2-to-8.3 planner changes. With these hooks in the core backend, development of the advisor can proceed as a pgfoundry project.</li>
<li>Remove ruleutils.c's use of varnoold/varoattno as a shortcut for determining what a Var node refers to. This is no longer necessary because the new flat-range-table representation of plan trees makes it relatively easy to dig down through child plan levels to find the original reference; and to keep doing it that way, we'd have to store joinaliasvars lists in flattened RTEs, as demonstrated by bug report from Leszek Trenkner. This change makes varnoold/varoattno truly just debug aids, which wasn't quite the case before. Perhaps we should drop them, or only have them in assert-enabled builds?</li>
<li>Avoid assuming that the fields of struct timeval have exactly type long. This is probably incorrect on some platforms, and definitely draws a compiler warning on Darwin.</li>
<li>Repair planner bug introduced in 8.2 by ability to rearrange outer joins: in cases where a sub-SELECT inserts a WHERE clause between two outer joins, that clause may prevent us from re-ordering the two outer joins. The code was considering only the joins' own ON-conditions in determining reordering safety, which is not good enough. Add a "delay_upper_joins" flag to OuterJoinInfo to flag that we have detected such a clause and higher-level outer joins shouldn't be permitted to commute with this one. (This might seem overly coarse, but given the current rules for OJ reordering, it's sufficient AFAICT.) The failure case is actually pretty narrow: it needs a WHERE clause within the RHS of a left join that checks the RHS of a lower left join, but is not strict for that RHS (else we'd have simplified the lower join to a plain join). Even then no failure will be manifest unless the planner chooses to rearrange the join order. Per bug report from Adam Terrey.</li>
<li>Fix best_inner_indexscan to return both the cheapest-total-cost and cheapest-startup-cost innerjoin indexscans, and make joinpath.c consider both of these (when different) as the inside of a nestloop join. The original design was based on the assumption that indexscan paths always have negligible startup cost, and so total cost is the only important figure of merit; an assumption that's obviously broken by bitmap indexscans. This oversight could lead to choosing poor plans in cases where fast-start behavior is more important than total cost, such as LIMIT and IN queries. 8.1-vintage brain fade exposed by an example from Chuck D.</li>
<li>Teach tuplestore.c to throw away data before the "mark" point when the caller is using mark/restore but not rewind or backward-scan capability. Insert a materialize plan node between a mergejoin and its inner child if the inner child is a sort that is expected to spill to disk. The materialize shields the sort from the need to do mark/restore and thereby allows it to perform its final merge pass on-the-fly; while the materialize itself is normally cheap since it won't spill to disk unless the number of tuples with equal key values exceeds work_mem. Gregory Stark, with some kibitzing from Tom Lane.</li>
</ul>
<p>Peter Eisentraut a commit&eacute;&nbsp;:</p>
<ul>

<li>In pgsql/contrib/xml2/README.xml2, add deprecation notice about planned removal in 8.4 and advice to try using the newer XML stuff in core. This should probably also be referred to in the release notes.</li>
<li>Nikolay Samokhvalov's xpath fixes, with code cleanup and documentation work by myself.</li>
<li>Fix spurious German index entry</li>
</ul>
<p>Michael Meskes a commit&eacute;&nbsp;:</p>
<ul>
<li>Removed errant ISODOW</li>
<li>Backported fix from HEAD that removes a superfluous function which Vista has a problem with.</li>
<li>Also removed the function not just the call, sorry.</li>

<li>Do not try to find local timezone in DecodeDateTime() because the result is not used anyway. This also fixes Vista's build problems.</li>
</ul>
<p><strong>Correctifs rejet&eacute;s (&agrave; ce jour)</strong></p>
<ul>
<li>Pas de d&eacute;ception cette semaine :-)</li>
</ul>
<p><strong>Correctifs en attente</strong></p>
<ul>
<li>Gregory Stark sent in another revision of his concurrent psql patch.</li>

<li>NikhilS sent in a patch implementing CREATE TABLE LIKE INCLUDING INDEXES.</li>
<li>Andrew Dunstan sent in several revisions of patches to UTF8MatchText.</li>
<li>Henry B. Hotz sent in another revision of his GSSAPI patch.</li>
<li>Greg Smith sent in another revision of his patch to enable COPY-able csv log outputs.</li>
<li>Arul Shaji sent in another revision of his patch to make cursors updateable.</li>
<li>Heikki Linnakangas sent in a several revisions of a Heikki/Simon collaboration on a "scan-resistant buffer manager" patch.</li>
</ul>
</html>
Communauté francophone de PostgreSQL

Outils pour utilisateurs

Outils du site

Outils de la page
