idn't watch the rebuild step very
> closely (or, heaven forbid, used make -s and didn't see anything),
> you could waste a lot of time before realizing that make hadn't
> done what it's supposed to.
make does what it is supposed to do here IIUC.
Then we may just want to move t
e.global.in (removing this target completely also fix
the
issue)
Hope it helps you and Peter find the good fix.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
a single sql
command)
BTW I can dump everything from port 5432, except extensions (I can even run
pg_basebackup instead of rsync !).
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This
, not to keep it in sync (just
use it to hide the complexity of locks).
Anyway that was just comments.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
.r.t
> Savepoint.
not a problem.
consider that pseudo code:
begin serializable;
update pg_settings; -- or whatever the name of the object (can include
creation of a table, etc...)
savepoint...
update pg_settings;
rollback to savepoint;
commit; <-- here the deferred trigger FOR STATEMENT o
Le vendredi 16 novembre 2012 07:16:09, Amit Kapila a écrit :
> On Thursday, November 15, 2012 11:28 PM Cédric Villemain wrote:
> > Le jeudi 15 novembre 2012 15:48:14, Amit kapila a écrit :
> > > On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote:
> > >
> >
;
> There would also be the advantage that pg_dumpall would save these
> settings.
>
> Thoughts?
I like the idea.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
it should be easier to have something transactional and also serializable
with probably a DEFERRABLE select pg_reload_config() which mv the configuration
file at commit time)
* Can I define automatic parameters to be loaded before and/or after the non-
automatic parameters in a convenient way (without ed
We do not understand why we can't obtain some improvments with previous
> changes. Did we do something wrong ?
Can you share the size of the tables ? (size , number of tuples, dead/live,
...) ? (please create a new thread in one of the other mailling-list)
--
Cédric Villemain +33 (0)6 2
d some information
regarding what is achieved around us.
>
> To which places are you referring to, btw?
Maintenance tasks.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
d to hack to make linux understand that we will
benefits from prefetching.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
F EXISTS on a single
> table, I think it's very very dubious to allow it in multi-table
> commands.
well, in such case you probably don't want to use IF EXISTS.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
le, an
> rsync comes along and copies the file, and then PG writes to that same
> file again, after the rsync is done, but within the same second. If the
> file size isn't changed by that write, a later rsync might feel that it
> isn't necessary to check if the file contents chan
> c) isn't necessarily safe in production (I've crashed Linux with Fincore
> in the recent past).
fincore is another soft, please provide a bugreport if you hit issue with
pgfincore, I then be able to fix it and all can benefit.
--
Cédric Villemain +33 (0)6 20 30 22 52
http:
~8*10^9 rows) which is basically using double space because it's primary
> > key is covering all columns of the table.
>
> I was wondering if there was some way to specify an expression index
> that did a unique index check on some columns but included more columns
>
> > anything else that is.
>
> To me, it looks like TODO is just a misnomer. The file should be named
> TODISCUSS, IDEAS, or something. But the current file name implies
> consensus.
>
> Wouldn't renaming solve that kind of misunderstanding? (..in the vain of
> "add
me longest job.
pgfincore allows since years to snapshot and restore the OS cache to work
around such issues.
Autovacuum should snapshot the xMB ahead and restore the previous state cache
when done.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Dévelop
gressive, because I'm pretty sure that ain't the issue.
we may need reserved workers to work on system tables, at least.
Just as a protection in case all workers all locked hours walking 'log'
tables. In the meantime, the pg_type table can bloat a lot for ex.
It might be that
we should have multiple option here
soon), dbname, user, inspecting pg_hba.conf will remain difficult if map
is
used or some other +group option.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
we?
I'll make it ready for. (not a huge task).
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
Le mercredi 20 juin 2012 21:53:43, Peter Eisentraut a écrit :
> On tis, 2012-04-10 at 13:29 +0200, Cédric Villemain wrote:
> > I have no problem deprecating overlapping features from pgfincore as
> > soon as I can do a «depend:pg_prewarm[os_warm]» :) ...It would have
> >
tore shared
> buffers. Not the OS cache, but we don't have portable code to query
> the OS cache yet anyway.
+pgfincore and the OS cache part is done.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
has been found, update the latest checkpoint and previous
>
> checkpoint.
>
> > Apart from above some changes in code will be required after the Xlog
>
> patch
>
> > by Heikki.
> >
> > Suggest me if my understanding is correct?
>
> I guess my firs
rs. We judged that he has the requisite skills,
> dedication to the project, and a suitable degree of caution to be
> a good committer. Please join me in welcoming him aboard.
very good news!
Congratulations Kevin.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.
ut the usagecount used.
Jeff suggested to maybe increase by 2 and decrease by 1. This is really near
another idea I had but I didn't tested yet. Increment/decrement by 1 or 2,
just make even numbers ascending, and odd number descending. So that by just
looking at the usage count you can k
ostgresql.org/community/contributors/
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
ome addition documentation examples also inspired
> by comments from Jeff.
Load-per-block is indeed very useful as the Slave can really catch-up more
quickly with the workload in case of switchover for example (this is why I've
moved pgfincore results in a varbit that can be shared with t
g_fincore;
(probably the same with pg_prewarm)
>
> -Stefan
>
> 2012/3/11 Cédric Villemain :
> > Le vendredi 9 mars 2012 16:50:05, Robert Haas a écrit :
> >> On Fri, Mar 9, 2012 at 10:33 AM, Dimitri Fontaine
> >>
> >> wrote:
> >> > So that
primer objective of posix_fadvise_dontneed is not to make sync() faster.
We just have writeback and sync() calls challenged together and we can face
situation where linux does not handle that so well. (depends on linux 2.6.18
or 32 or 3.2 or ...)
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
t; > to maintain its data set on disk, though.
>
> That's an interesting idea. It seems tricky, though.
it is the purpose of the latest pgfincore version.
I use a varbit as output of introspection on master, then you are able to
store in a table, stream to slaves, then replay localy.
"?dbname=other" looks like dbname is an argument, but dbname is a requirement
for postgresql connexion.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ng said, I am surprised that the pattern "create table...analyze
create table analyze" of such smalls ones make the data being flush from OS
cache so quickly that they need to be read again from disk.
Pavel, can you check the cache status of the tables just before the analyze ?
(
ng said, I am surprised that the pattern "create table...analyze
create table analyze" of such smalls ones make the data being flush from OS
cache so quickly that they need to be read again from disk.
Pavel, can you check the cache status of the tables just before the analyze ?
(
"?dbname=other" looks like dbname is an argument, but dbname is a requirement
for postgresql connexion.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Le 28 janvier 2012 21:46, David E. Wheeler a écrit :
> On Jan 27, 2012, at 2:19 AM, Cédric Villemain wrote:
>
>>> Also --exclude-extension?
>>
>> It might be the default.
>> We need something to dump the content of
>> pg_catalog.pg_extension_script (or wh
mp the content of
pg_catalog.pg_extension_script (or whatever table is going to contain
SQL code), per extension or all.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
he planner need
to be revisited. Please Tom, keep on.
And it might be that 9.2 is a very good release to do that because if
there is performance impact from this patch (at the end), there are so
many improvment in other places that it should be easely compensated
for users. It might be harder to do
e_directory, then running the current code.
>
> I can adapt the patch to this behavior this week.
if we agree to have that per cluster, then it can be in the
$pgdata/pg_extension or something similar...
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
te extension directly in plain sql,
without file creation or access or system administrators privileges.
Why wouldn't we want that ?!
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Sent via pgsql-ha
l.
what about a long extra option: --inserts like pg_dump ?
pgbench -i --inserts ...
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
2011/11/9 Robert Haas :
> On Wed, Nov 9, 2011 at 8:37 AM, Cédric Villemain
> wrote:
>> Maybe I miss something but:
I read that the error was produced by first session and didn't check
carefuly (it fails silently in 9.0! and 'works' as expected in 9.1)
No objection, b
op+create would success ?!
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgr
2011/11/4 Josh Kupershmidt :
> On Fri, Nov 4, 2011 at 10:05 AM, Magnus Hagander wrote:
>> On Fri, Nov 4, 2011 at 14:53, Cédric Villemain
>>> Interesting, can the ouput be clear on the value being a default or an
>>> explicit stat target ? (not mandatory but I believe
tion:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
gt; Regards,
> Marti
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Sup
ng /tmp for sockets allows everyone to spoof a PostgreSQL server. Thus use
/var/run/postgresql/ for "system" clusters which run as 'postgres' (user
clusters will still use /tmp). Since system cluster are by far the common case,
set it as default.
--
Cédric Villema
that pg_config may
output it, but the solution that most people seems to agree at this
time was to add a configure option. Except that we didn't want to
encourage people to change the default_socket_dir, so a documentation
update in this direction was suggested to be done at the same time the
swit
izeof(BufferStrategyControl), 1);
>> + }
>> }
>>
>>
>> @@ -521,3 +527,47 @@ StrategyRejectBuffer(BufferAccessStrategy strategy,
>> volatile BufferDesc *buf)
>>
>> return true;
>> }
>> +
>> +/*
>> + * AdjustStrategyControl -- adjust the me
let DBA use its knowledge if he wants, but 3
make it mandatory for the DBA to decide, and no automatic way can be
used to update it, except if someone make ALTER TABLE lock free)
(It does not prevent a cost_indexonly() to be written meawhile...)
What do you think/prefer/suggest ?
--
Cédric
sting to add a "vacuum freeze"
somewhere and check expected result after index-only scan ? (for both
idx_tup_read and idx_tup_fetch)
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make chan
k ok enough in all others. Need to be carefull about
> the usual O_DIRECT pitfalls (pagesize, alignment etcetera).
> - use mmap/mincore() to gather whether data is in cache and restore that state
> afterwards.
>
> Too bad that POSIX_FADV_NOREUSE is not really implemented.
yes.
>
&g
hp]
> - Script to compute random page cost
> [http://archives.postgresql.org/pgsql-hackers/2002-09/msg00503.php]
> - The science of optimization in practical terms?
> [http://archives.postgresql.org/pgsql-hackers/2009-02/msg00718.php], getting
> really interesting sta
2011/9/23 Cédric Villemain :
> 2011/9/23 Robert Haas :
>> On Thu, Sep 22, 2011 at 12:45 PM, Fujii Masao wrote:
>>> Agreed. Attached is the updated version of the patch. It adds two options
>>> --replication and --no-replication. If neither specified, neither
>>&g
or the documentation: a
superuser, even with NOREPLICATION is allowed to perform
pg_start_backup() and pg_stop_backup().
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2nd
name?
>>
>> Better solution: don't have a short form of the switch.
>
> That sounds better. I revised the patch so that it adds only "--replication"
> option to createuser.
>
> Regards,
>
> --
> Fujii Masao
> NIPPON TELEGRAPH AND TELEPHONE C
--
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Cédric Villemain +33 (0)6 20 3
server class motherboards don't even have a x16 PCI-e slot on
> them, which is what most GPUs as delivered on regular consumer video cards
> are optimized for.
>
Sandy bridge and ivy bridge intel series are CPU/GPU. I don't know how
using the GPU affect the CPU part bu
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Dével
2011/8/31 Peter Eisentraut :
> On ons, 2011-08-31 at 11:18 +0200, Cédric Villemain wrote:
>> Just a question: can we build a different postgresql.conf for windows
>> or do we add a windows command example here as well ?
>
> Well, we could make initdb patch it up, but that
>
> Objections?
No objections, it is welcome.
Just a question: can we build a different postgresql.conf for windows
or do we add a windows command example here as well ?
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your
2011/8/12 Robert Haas :
> On Fri, Aug 12, 2011 at 6:20 AM, Cédric Villemain
> wrote:
>>>> Can this faux heap tuple be appended by the data from another index
>>>> once it has been created ? ( if the query involves those 2 index)
>>>
>>> I don't
; required for a range of potential futures.
>
> Are there objections to this work beginning?
No objections. (+100 for doing that)
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Sent via pg
2011/8/12 Robert Haas :
> On Thu, Aug 11, 2011 at 5:39 PM, Cédric Villemain
> wrote:
>> 2011/8/11 Robert Haas :
>>> Please find attached a patch implementing a basic version of
>>> index-only scans. This patch is the work of my colleague Ibrar Ahmed
>>>
nodeIndexscan.c builds up the faux heap tuple is
> perhaps susceptible to improvement. I thought about building a
> virtual tuple, but then what do I do with an OID column, if I have
> one? Or maybe this should be done some other way altogether.
Can this faux heap tuple be appe
t;
>
> Jun Ishizuka
> NTT Software Corporation
> TEL：045-317-7018
> E-Mail: ishizuka@po.ntts.co.jp
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To ma
That's being said I have no strong opinion for the HINT message if the
documentation is clear enough to not confuse DBA.
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hac
I would suggest to split each
in a separate patch proposal.
The \lf is a must have, imo.
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
ly.
So... if one want to make progress in the meantime, please do.
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
riosity, does it affect the previous benchmarks of the feature ?
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
2011/6/20 Robert Haas :
> On Mon, Jun 20, 2011 at 9:15 AM, Cédric Villemain
> wrote:
>> The feature does not work exactly as expected because the write limit
>> is rounded per 8kB because we write before checking. I believe if one
>> write a file of 1GB in one pass (i
2011/6/17 Cédric Villemain :
> 2011/6/17 Mark Kirkwood :
>> On 17/06/11 13:08, Mark Kirkwood wrote:
>>>
>>> On 17/06/11 09:49, Cédric Villemain wrote:
>>>>
>>>> I have issues applying it.
>>>> Please can you remove trailing space?
>
/* if a plugin is present, let it manage things */
if (OSCache_hook)
percent = (*OSCache_hook) (relation, forkNum);
return percent;
}
Looks like the main fear is because I used the ANALYZE word...
PS: ANALYZE OSCACHE does *not* run with ANALYZE, those are distinct
operations. (ANALYZE won't do the job of ANALYZE OSCACHE, we can
discuss the grammar, maybe a ANALYZE ([OSCACHE], [DATA], ...) will be
better ).
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2011/6/19 Robert Haas :
> On Sun, Jun 19, 2011 at 11:12 AM, Cédric Villemain
> wrote:
>>> Good point --- we would be making plan decisions based on the visibility
>>> map coverage. The big question is whether visibility map changes are
>>> more dynamic than t
2011/5/11 Bruce Momjian :
> Cédric Villemain wrote:
>> 2011/5/10 Kevin Grittner :
>> > Simon Riggs wrote:
>> >> The typical speed up for non-covered indexes will come when we
>> >> access a very large table (not in cache) via an index scan that is
>>
2011/5/14 Robert Haas :
> On Fri, May 13, 2011 at 6:34 PM, Cédric Villemain
> wrote:
>> If reviewers agree it is safe and benchmarks make evidences that no
>> basic performance issue are raised, then let's see if next items have
>> blockers or can be done.
>
&
verage over time and discounting the
> estimates with some heuristic values.
yes, definitively something to think about. My biggest fear here is
for shared servers (when there is competition between services to use
the OS cache, shooting down kernel cache strategies).
--
Cédric Villemain
2011/6/17 Mark Kirkwood :
> On 17/06/11 13:08, Mark Kirkwood wrote:
>>
>> On 17/06/11 09:49, Cédric Villemain wrote:
>>>
>>> I have issues applying it.
>>> Please can you remove trailing space?
>>> Also, you can generate a cool patch like thi
2011/6/15 Mark Kirkwood :
> On 15/06/11 02:52, Cédric Villemain wrote:
>>
>> 2011/6/3 Mark Kirkwood:
>>>
>>> Corrected v4 patch with the test files, for completeness. Note that
>>> discussion has moved on and there will be a v5 :-)
>>>
>> Ma
ra
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-ha
2011/6/14 Robert Haas :
> On Tue, Jun 14, 2011 at 12:06 PM, Cédric Villemain
> wrote:
>>> 1. ANALYZE happens far too infrequently to believe that any data taken
>>> at ANALYZE time will still be relevant at execution time.
>>
>> ANALYZE happens when people exe
2011/6/14 Robert Haas :
> On Tue, Jun 14, 2011 at 10:29 AM, Cédric Villemain
> wrote:
>> 0001-Add-reloscache-column-to-pg_class.patch
>> 0002-Add-a-function-to-update-the-new-pg_class-cols.patch
>> 0003-Add-ANALYZE-OSCACHE-VERBOSE-relation.patch
>> 0004-Add-a-Hook
est files, for completeness. Note that
> discussion has moved on and there will be a v5 :-)
>
Mark, can you submit your updated patch ?
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing lis
2011/5/16 Greg Smith :
> Cédric Villemain wrote:
>>
>>
>> http://git.postgresql.org/gitweb?p=users/c2main/postgres.git;a=shortlog;h=refs/heads/analyze_cache
>>
>
> This rebases easily to make Cedric's changes move to the end; I just pushed
> a version
ert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Cédric
2011/6/2 Mark Kirkwood :
> On 01/06/11 09:24, Cédric Villemain wrote:
>> * I am not sure it is better to add a fileSize like you did or use
>> relationgetnumberofblock() when file is about to be truncated or
>> unlinked, this way the seekPos should be enough to increase
I think
> this is something different.
I am not specially attached to a name, idea was not to use work_disk
but backend_work_disk. I agree with you anyway, and suggestion from
Tom is fine for me (temp_file_limit).
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb
the same
conclusion and put it in a more appropriate place : before
ExecScanHashBucket.
I was about sending it, so it is attached.
>
> regards, tom lane
>
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formatio
; Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ha
2011/6/1 Robert Haas :
> On Tue, May 31, 2011 at 8:43 PM, Cédric Villemain
> wrote:
>> Yes, while here I noticed that the query was long to be killed.
>> I added a CHECK_FOR_INTERRUPT() in the for(;;) loop in nodeHashjoin.c.
>> It fixes the delay when trying to kil
Scan on "message_box_Idx"
> (cost=0.00..536.94 rows=28858 width=0) (actual time=1.743..1.743
> rows=20903 loops=113)
> Index Cond: (box_id = b.id)
> - Total runtime: 431520.186 ms
> + Total runtime: 6940.369 ms
>
> That's pretty od
h Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to read.
I like the idea and it sounds useful.
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d can work with
read-with-holes (if the holes are not larger than the read-ahead
window) and 2. if holes are that large then maybe it is not so good to
keep a larger read-ahead window (which keep trashing our buffer
cache).
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/
blkno >
> SKIP_PAGES_THRESHOLD)
> + skipping_all_visible_blocks = true;
> else
> ! skipping_all_visible_blocks = false;
> ! all_visible_according_to_vm = false;
> ! }
&g
ariable is clearly unused
> I went ahead and pushed this. Thanks
I have a recent gcc wich probably help here:
gcc-4.6.real (Debian 4.6.0-7) 4.6.1 20110507 (prerelease)
>
> --
> Álvaro Herrera
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consultin
2011/5/27 Cédric Villemain :
> 2011/5/27 Pavan Deolasee :
>> I wonder if we have tested the reasoning behind having
>> SKIP_PAGES_THRESHOLD and the magic number of 32 assigned to it
>> currently. While looking at the code after a long time and doing some
>> tests, I re
lready.
>
> Thanks,
> Pavan
>
>
>
>
>
> --
> Pavan Deolasee
> EnterpriseDB http://www.enterprisedb.com
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpre
that part. Interesting.
(If I dive correctly, we search our last segment and then use a
fileseek to the end of this segment to get our information)
make more sense, suddendly :)
>
> --
> Álvaro Herrera
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Cons
at.st_size, is it really what we want?)
>
> --
> Álvaro Herrera
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to
101 - 200 of 336 matches
Mail list logo
