Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

Le 23 juil. 2015 19:27, "Alvaro Herrera" a écrit : > > Laurent Laborde wrote: > > > Friendly greetings ! > > > > What's the status of parallel clusterdb please ? > > I'm having fun (and troubles) applying the vacuumdb patch to clusterdb.

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Fri, Jan 2, 2015 at 3:18 PM, Amit Kapila wrote: > > > Okay, I have marked this patch as "Ready For Committer" > > Notes for Committer - > There is one behavioural difference in the handling of --analyze-in-stages > switch, when individual tables (by using -t option) are analyzed by > using thi

Re: [HACKERS] dead assignment src/bin/scripts/print.c line 421

Should have been sent to the bugs ML sorry :-/ On Mon, Jul 13, 2015 at 3:56 PM, Laurent Laborde wrote: > Friendly greetings ! > > in file src/bin/scripts/print.c line 421 : > need_recordsep = false; > then set to true line 424. > > Now i'm pretty sure it's

[HACKERS] dead assignment src/bin/scripts/print.c line 421

Friendly greetings ! in file src/bin/scripts/print.c line 421 : need_recordsep = false; then set to true line 424. Now i'm pretty sure it's a meaningless "bug" without any consequence (the commit that introduced it is 15 years old). There is a lot of (apparently) dead assignment here and there b

Re: [HACKERS] Cost of sort/order by not estimated by the query planner

The table is clustered by by blog_id. So, for testing purpose, i tried an ORDER BY blog_id. limit 500 : - explain analyze SELECT * FROM _article WHERE (_article.bitfield && getbit(0)) ORDER BY _article.blog_id ASC LIMIT 500; Limit (cost=66229.90..66231.15 rows=500 width=1099) (act

Re: [HACKERS] Cost of sort/order by not estimated by the query planner

'morning ! And here is the query plan for : --- explain analyze SELECT * FROM _article WHERE (_article.bitfield && getbit(0)) ORDER BY _article.id ASC LIMIT 5; Limit (cost=0.00..2238.33 rows=5 width=1099) (actual time=17548636.326..17548837.082 rows=5 loops

Re: [HACKERS] Cost of sort/order by not estimated by the query planner

hummm Adding pgsql-perf :) On Mon, Nov 30, 2009 at 5:54 PM, Laurent Laborde wrote: > Friendly greetings ! > I use postgresql 8.3.6. > > here is a few info about the table i'm querying : > - > - select

[HACKERS] Cost of sort/order by not estimated by the query planner

Friendly greetings ! I use postgresql 8.3.6. here is a few info about the table i'm querying : - - select count(*) from _article : 17301610 - select count(*) from _article WHERE (_article.bitfield && getbit(0)) : 6729 Here are both requ

Re: [HACKERS] Higher TOAST compression.

On Tue, Jul 28, 2009 at 2:36 PM, Laurent Laborde wrote: > I'm currently rewriting the whole toaster stuff to simply define : > - a compression threshold (size limit to compress, in Nth of page) > - an external threshold (size limit to externalize compressed data, in > Nth of pag

Re: [HACKERS] Higher TOAST compression.

ot of trial and error as it will my first real patch. http://github.com/ker2x/AkaneSQL/tree/master as usual. -- F4FQM Kerunix Flan Laurent Laborde -- 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] Higher TOAST compression.

On Thu, Jul 23, 2009 at 4:45 PM, Kevin Grittner wrote: > Laurent Laborde wrote: > >> (iostat show a 5~25MB/s bandwidth at 100%util instead of 2~5MB/s at >> 100%util). > > Any numbers for overall benefit at the application level? > >> So... now i'm not sur

Re: [HACKERS] Higher TOAST compression.

On Wed, Jul 22, 2009 at 10:54 AM, Laurent Laborde wrote: > My 1st applied patch is the safest and simpliest : > in pg_lzcompress.c : > > static const PGLZ_Strategy strategy_default_data = { >        256,    /* Data chunks less than 256 are not compressed */ >        256,    /* fo

Re: [HACKERS] Higher TOAST compression.

ds are french text and html. (blog data : articles, comments, ...) Thank you. -- Laurent Laborde Sysadmin @ http://www.over-blog.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] Higher TOAST compression.

i will try and report different strategy here. Thank you again for your feedback. -- Laurent Laborde Sysadmin @ http://www.over-blog.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] Higher TOAST compression.

_data; Isn't it ? What about setting "PGLZ_strategy_always" as the default strategy (insane cpu cost ?) ? Or something in-between ? Thank you. -- Laurent Laborde Sysadmin @ http://www.over-blog.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or

Re: [HACKERS] Higher TOAST compression.

On Fri, Jul 17, 2009 at 11:10 PM, Kevin Grittner wrote: > Laurent Laborde wrote: > >> What about SET STORAGE MAIN then ? To prevent out-of-line storage ? > > Well, that doesn't try as hard as you might think to keep from storing > data out-of-line.  It uses the sam

Re: [HACKERS] Higher TOAST compression.

On Fri, Jul 17, 2009 at 10:40 PM, Kevin Grittner wrote: > Laurent Laborde wrote: > >> But... on which version are you planning to do that ? > > The patch, if there's consensus that it's a good idea, would be for > 8.5.  Since it is new functionality, there wou

Re: [HACKERS] Higher TOAST compression.

find a better upgrade solution. The proposed solution sound really good to me. But, for now, if i could have a simple patch for 8.3 (eg: changing a #define in the source code), i'd be very happy :) Is it ok to just change TOAST_TUPLES_PER_PAGE ? Thank you for all your replies and proposed s

[HACKERS] Higher TOAST compression.

. Any tought ? idea ? Thank you. -- F4FQM Kerunix Flan Laurent Laborde -- 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] create if not exists (CINE)

ant to add a DROP IF EXISTS because it will drop the content of the materialized view on the master, and will replace it with an empty regular table. Solution : If i had a "CREATE IF NOT EXISTS", the script won't fail on the master and will execute correctly on all nodes. Thank you

[HACKERS] high shared buffer and swap

in OS filesystem cache and 1 in shm (shared_buffer)). I'd love to understand what's happening here ! Thank you :) -- F4FQM Kerunix Flan Laurent Laborde -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Perl coding style in postgresql

will happily patch all perl files ( according to http://wiki.postgresql.org/wiki/Submitting_a_Patch ) once the most basic rule are defined :) *hugs* -- Laurent Laborde Sysadmin at jfg://networks http://www.over-blog.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] Keyword list sanity check

gory, and > conversely that all keywords listed in kwlist.h are listed in gram.y. Friendly greetings ! Here is a new version of check_keywords.pl : - perl -w and "use strict" enabled (and all the fixes that come with it) - minor cleaning -- Laurent Laborde Sysadmin at jfg://ne

Re: [HACKERS] Extend PL/pgSQL

is is a bad practice, however, I > wanted to know if it's possible to implement this feature. If it's possible, > I wonder if a developer could add this feature. Sure ! Here it is : http://tinyurl.com/anel > Thank you in advance, send me an email if you have an answer. yw :)

Re: [HACKERS] pg_restore --multi-thread

tore will not limit the number of > jobs that can run simultaneously. I like both -j and -w. -j because we all know "make -j" -w because i like --num-workers -- F4FQM Kerunix Flan Laurent Laborde -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)