end ==
>
> The full list of SHOW commands, should anyone be interested, is at
> http://dev.mysql.com/doc/en/show.html
>
> Cheers,
> Baron
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://ww
2009/12/23 Tom Lane :
> =?ISO-8859-1?Q?C=E9dric_Villemain?=
> writes:
>> I wonder what is the future of "_PG_fini", documentation say at [1]:
>> "Note that _PG_fini will only be called during an unload of the file,
>> not during process termination. (Presently, unloads are disabled and
>> will ne
"
Since 8.2 it is the same and no entry in the TODO list for that, also
I didn't find mails about that in the pgsql-hackers ML archive.
So:
1. do we want a _PG_fini which is call on server stop ?
2. what's actually the best way to execute some code when server stop,
if one hav
2009/12/22 Takahiro Itagaki :
>
> Cedric Villemain wrote:
>
>> Le vendredi 18 decembre 2009 09:44:40, Takahiro Itagaki a ecrit :
>> > I'd like to add per-query buffer usage into contrib/pg_stat_statements.
>
> Here is a patch to add buffer usage columns into pg_stat_statements.
> It also changes i
2009/12/21 Tom Lane :
> Greg Smith writes:
>> To answer Rafael's concerns directly: you're right that this is
>> confusing. pg_relation_size is always going to do what it does right
>> now just because of how that fits into the design of the database.
>> However, the documentation should be upda
mputed
in the view ?
>
> Regards,
> ---
> Takahiro Itagaki
> NTT Open Source Software Center
>
--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
tead of naming a
> directory. Because packaging tools, editors, etc. will leave backup and
> temporary files lying around that you don't want to include, and we
> don't want to get involved into knowing all the naming patterns that
> people might want to use for those.
>
>
what "fadvise -dontneed" let you do ?
Josh, I talk about effective_cache_size per tablespace *exactly* for the
reason you explain.
--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
Le vendredi 23 octobre 2009 14:23:09, Robert Haas a écrit :
> On Fri, Oct 23, 2009 at 5:23 AM, Cédric Villemain
>
> wrote:
> > Le vendredi 23 octobre 2009 01:08:15, Joshua D. Drake a écrit :
> >> On Thu, 2009-10-22 at 11:33 -0400, Robert Haas wrote:
> >> &
Le vendredi 23 octobre 2009 01:08:15, Joshua D. Drake a écrit :
> On Thu, 2009-10-22 at 11:33 -0400, Robert Haas wrote:
> > On Thu, Oct 22, 2009 at 11:16 AM, Cédric Villemain
> >
> > wrote:
> > > Le lundi 19 octobre 2009 23:27:20, Greg Stark a écrit :
> >
ers which the planner and other
> systems check on the appropriate table and default to the global GUC
> if they're not set.
>
--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
eq_page_cost"
> setting for each TABLESPACE, to compensate for the fact that different
> media might be faster or slower, and a percent-cached setting for each
> table over top of that.
At least settings by TABLESPACE should exists. I totaly agree with that.
>
> ...Robert
>
--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
riting up. Allowing a user-set value for that is a lot more
> reasonable if the system computes a reasonable one itself under normal
> circumstances. That's what I think people really want, even if it's not
> what they're asking for.
Have you already some work in a
need to be change in the US...
Something else ? :p
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
Le mercredi 12 août 2009, Greg Stark a écrit :
> On Wed, Aug 12, 2009 at 3:07 PM, Cédric
>
> Villemain wrote:
> > I wonder if POSIX_FADV_RANDOM and POSIX_FADV_SEQUENTIAL are still
> > innacurate for postgreSQL ?
> >
> > I find
> > «A related problem is that
27;t a lot of code there.
» (ron mayer, 2006)
But that seems a bit old.
----
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cédric Villemain a écrit :
> Joshua D. Drake a écrit :
>> On Thu, 2009-02-12 at 11:47 -0500, Andrew Dunstan wrote:
>>> Joshua D. Drake wrote:
>>>> On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
>&g
rminology on platforms where
>>>> there is no threading involved.
>>>>
>>> --num-workers or --num-connections would both work.
>>>
>>>
>> *shrug* whatever. What should the short option be (if any?). -n is
>> taken, so -N ?
>
please give the link to this list of feature ?
> you will see that it
> doesn't come close. We can always argue if his list is reasonable :-),
> but that's just a fact. It has nothing about round-robin reviewers. It
> has no keep-track-of-nagging features. It has no int
python code. If it is full of escaped
characters it can turn unreadable by a human. (we, at dalibo, used to write our
docs with ReST and most of the time we don't need to escape special char).
I don't follow 0 or 2..
- --
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74
. I think that this proposal is still useful for those that need
> something quick and dirty though.
>
Can be interesting, but for my own usage "border=3" will be enough.
- --
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http
instead. That's if there is any difference of
>> course. We could document "border 4" as ReST with no change to my code
>> patch until we find some case where "border 3" breaks ReST.
>
> See above, there are lots of cases, and we aren't going to
t the SQL standard requires parentheses, like
>
> TRUNCATE ONLY (a), b
>
> which is clearer. While we support that in gram.y, I don't see it
> anywhere in the documentation.
>
> Should we document this and emphasize it as having more clarity?
>
+1
- --
Cédric Villemain
ed anywhere that it is *ReSt output*.
If needed, a 'case PRINT_REST' in print.c is still possible... or let user
define output format as suggested by D'arcy J.M. Cain.
--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
.
We use ReST a lot, and it will be very usefull to have this ouput.
>
> --
> * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
Le Monday 21 July 2008, Heikki Linnakangas a écrit :
> Cédric Villemain wrote:
> > Le Monday 21 July 2008, Heikki Linnakangas a écrit :
> >> I think we should differentiate between "infinite" and "unknown" in the
> >> return value of get_stack_depth_
t; in case of infinite, and fall back to the 100kB only in the unknown case.
Why 2MB ? I believed that 3.5MB is the effective good maximum , is that too
much ?
>
> --
>Heikki Linnakangas
>EnterpriseDB http://www.enterprisedb.com
--
Cédric Villemain
Administrateur de Base d
Le Wednesday 16 April 2008, Magnus Hagander a écrit :
> Cédric Villemain wrote:
> > Notice that :
> >
> > http://search.postgresql.org/search?q=tom+lane&m=1&l=&d=1&s=r
> > and
> > http://search.postgresql.org/search?q=tom+lane&m=1&l=&d=1
Notice that :
http://search.postgresql.org/search?q=tom+lane&m=1&l=&d=1&s=r
and
http://search.postgresql.org/search?q=tom+lane&m=1&l=&d=1&s=d
do not provide same result (3 results by date, 1 by rank) even if only the
sorting is changed.
--
Cédric Villemain
A
get rid of the limit of 1000, adequately document
> whatever issues might exist with large values (possibly not many, see
> above), and add an error message more user-friendly than "invalid memory
> alloc request size" for the cases where the value is too large to be
> storable.
--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
---(end of broadcast)---
TIP 6: explain analyze is your friend
--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
---(end of broadcast)---
TIP 4:
Gregory Stark a écrit :
"Tiago J. Adami" <[EMAIL PROTECTED]> writes:
The issue topics:
1) As the database grows on our customers, lower performance occurs. After
one week of use, the I/O on database is extremely high. It appears that
VACUUM FULL and/or VACUUM ANALYZE doesn't work on this dat
conds to restore
respectively copy, mutiinserts and inserts.
>
> regards, tom lane
>
> ---(end of broadcast)---
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
--
guidelines ?
--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
r just let people use this method :
http://momjian.us/expire/textsearch/HTML/textsearch-parser-example.html ?
--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
Le vendredi 30 mars 2007 12:36, Marko Kreen a écrit :
> Patch:
>
> http://plproxy.projects.postgresql.org/plproxy_core.diff.gz
Note a perhaps oversight in your makefile :
+ #REGRESS_OPTS
= --dbname=$(PL_TESTDB) --load-language=plpgsql --load-language=plproxy
+ REGRESS_OPTS
= --dbname=regressio
301 - 336 of 336 matches
Mail list logo
