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

Le 23 juil. 2015 19:27, Alvaro Herrera alvhe...@2ndquadrant.com 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. This thread also talk about unifying code

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

On Fri, Jan 2, 2015 at 3:18 PM, Amit Kapila amit.kapil...@gmail.com 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

[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

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 kerdez...@gmail.com 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 a meaningless bug without

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

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)

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 kerdez...@gmail.com wrote: Friendly greetings ! I use postgresql 8.3.6. here is a few info about the table i'm querying : - - select count(*) from

[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

Re: [HACKERS] Higher TOAST compression.

On Thu, Jul 23, 2009 at 4:45 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: Laurent Laborde kerdez...@gmail.com 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 sure

Re: [HACKERS] Higher TOAST compression.

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 Tue, Jul 28, 2009 at 2:36 PM, Laurent Labordekerdez...@gmail.com 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 page)

Re: [HACKERS] Higher TOAST compression.

On Wed, Jul 22, 2009 at 10:54 AM, Laurent Labordekerdez...@gmail.com 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,    /* force

Re: [HACKERS] Higher TOAST compression.

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.

On Fri, Jul 17, 2009 at 11:10 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: Laurent Laborde kerdez...@gmail.com 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

Re: [HACKERS] Higher TOAST compression.

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.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Higher TOAST compression.

. 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

[HACKERS] Higher TOAST compression.

? 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] Higher TOAST compression.

here :) -- Laurent Laborde Sysadmin at 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.

On Fri, Jul 17, 2009 at 10:40 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: Laurent Laborde kerdez...@gmail.com 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

Re: [HACKERS] create if not exists (CINE)

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 -- Laurent Laborde Sysadmin at jfg://networks -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

[HACKERS] high shared buffer and swap

(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

) 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

in kwlist.h in the right category, 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

Re: [HACKERS] Extend PL/pgSQL

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 :) -- F4FQM Kerunix Flan Laurent

Re: [HACKERS] pg_restore --multi-thread

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) To make changes to your subscription: http