[HACKERS] Proposal of SE-PostgreSQL patches [try#2]

Hi, The following patch set is our second proposals of SE-PostgreSQL. It contains many of fixes and improvements from the previous version. Please add them a reviwing queue of the next commit fest. Thanks, List of Patches === [1/4] Core facilities of PGACE/SE-PostgreSQL http:/

Re: [HACKERS] pg_stat_statements

On Mon, 2008-06-23 at 15:22 +0900, ITAGAKI Takahiro wrote: > I wrote: > > I will try to measure overheads of logging in some implementation: > > 1. Log statements and dump them into server logs. > > 2. Log statements and filter them before to be written. > > 3. Store statements in shared mem

[HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

I was thinking a bit about how we pad columns of type NAME to fixed-width, even though they're semantically equivalent to C strings. The reason for wasting that space is that it makes it possible to overlay a C struct onto the leading columns of most system catalogs. I don't wish to propose changin

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

I would mention in the C comment that we are doing this for space savings, but other than that, it seems fine. --- Tom Lane wrote: > I was thinking a bit about how we pad columns of type NAME to > fixed-width, even though th

Re: [HACKERS] Remove hacks for old bad qsort() implementations?

Added to TODO: * Consider whether duplicate keys should be sorted by block/offset http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php --- Tom Lane wrote: > There are several places in tuplesort.c (and perh

Re: [HACKERS] [PATCHES] Database owner installable modules patch

Added to TODO: * Implement a module capability for loading /contrib-style extensions http://archives.postgresql.org/pgsql-patches/2008-04/msg00164.php --- Tom Dunstan wrote: > Hi all > > Here is a patch that provides a

Re: [HACKERS] Kludge in pg_standby.c

Alvaro Herrera wrote: > > Gregory Stark wrote: > > > > > > There's a suspicious ifdef in pg_standby for WIN32 which smells like a > > > kludge > > > added to work around a Windows problem which makes it work but at great > > > expense: > > > > > > #ifdef WIN32 > > > /* > > >

Re: [HACKERS] stat() vs cygwin

Magnus, was this fixed/resolved? --- Magnus Hagander wrote: > It seems my fix for stat() broke cygwin, because it doesn't have > dosmaperr() available. The way I see it there are two ways to fix this: > > 1) Don't apply the

Re: [HACKERS] Kludge in pg_standby.c

On Mon, 2008-06-23 at 17:38 -0400, Bruce Momjian wrote: > Is this fixed and this block of code can be removed? There'll be some action for the next CommitFest. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

Tom Lane wrote: Cutting a third off the size of a system index has got to be worth something, but is it worth a hack as ugly as this one? I think so. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.p

Re: [HACKERS] count(*) performance improvement ideas

Added to TODO: * Allow custom variables to appear in pg_settings() --- Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Really? [ pokes around ... ] Hm, you're right, because

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

On Mon, 2008-06-23 at 15:52 -0400, Tom Lane wrote: > CVS HEADw/patch savings > > pg_database_size('postgres') 4439752 4071112 8.3% > pg_relation_size('pg_class_relname_nsp_index')57344 40960 > 28%

Re: [HACKERS] Lessons from commit fest

What is our plan for pgindent for 8.4? I would rather not have to bug someone to create a list of symbols manually. I would like it to be built on a regular basis and I can pull it from there and add it to CVS when I run pgindent. -

Re: [HACKERS] Lessons from commit fest

I will try to look at it again in a few days. cheers andrew Bruce Momjian wrote: What is our plan for pgindent for 8.4? I would rather not have to bug someone to create a list of symbols manually. I would like it to be built on a regular basis and I can pull it from there and add it to CVS w

Re: [HACKERS] Timely reporting of COPY errors

Added to TODO: o Allow COPY to report errors sooner http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php --- Martijn van Oosterhout wrote: -- Start of PGP signed section. > Hi, > > I notice

Re: [PATCHES] [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

Alex Hunsaker wrote: > On Wed, Apr 16, 2008 at 4:54 PM, Alvaro Herrera > <[EMAIL PROTECTED]> wrote: > > Joshua D. Drake escribi?: > > > > > That is an interesting idea. Something like: > > > > > > pg_restore -E "SET STATEMENT_TIMEOUT=0; SET MAINTENANCE_WORK_MEM=1G" ? > > > > We already have it -

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

Andrew Dunstan wrote: Tom Lane wrote: Cutting a third off the size of a system index has got to be worth something, but is it worth a hack as ugly as this one? I think so. Were you able to time any speedup? Is this something that would benefit installations with a lot of metadata? I pr

Re: [HACKERS] [PATCHES] Testing pg_terminate_backend()

Can we conclude this has been tested enough for 8.4? --- Magnus Hagander wrote: > Bruce Momjian wrote: > > Magnus Hagander wrote: > > > It looks pretty good from here. I have an output of about 50 million > > > lines, and th

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

Mark Mielke <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> Cutting a third off the size of a system index has got to be worth >>> something, but is it worth a hack as ugly as this one? > Were you able to time any speedup? I didn't try; can you suggest any suitable benchmark? The performance

Re: [PATCHES] [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

On Mon, Jun 23, 2008 at 06:51:28PM -0400, Bruce Momjian wrote: > Alex Hunsaker wrote: > > On Wed, Apr 16, 2008 at 4:54 PM, Alvaro Herrera > > <[EMAIL PROTECTED]> wrote: > > > Joshua D. Drake escribi?: > > > > > > > That is an interesting idea. Something like: > > > > > > > > pg_restore -E "SET ST

Re: [PATCHES] [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

daveg wrote: > On Mon, Jun 23, 2008 at 06:51:28PM -0400, Bruce Momjian wrote: > > Alex Hunsaker wrote: > > > On Wed, Apr 16, 2008 at 4:54 PM, Alvaro Herrera > > > <[EMAIL PROTECTED]> wrote: > > > > Joshua D. Drake escribi?: > > > > > > > > > That is an interesting idea. Something like: > > > > > >

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

Simon Riggs <[EMAIL PROTECTED]> writes: > On Mon, 2008-06-23 at 15:52 -0400, Tom Lane wrote: >> Cutting a third off the size of a system index has got to be worth >> something, but is it worth a hack as ugly as this one? > Not doing it would be more ugly, unless there is some negative > side-effec

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

Tom Lane wrote: Were you able to time any speedup? I didn't try; can you suggest any suitable benchmark? Unfortunately - no. I kind of think it won't benefit any of my databases in any noticeable way. My numbers are similar to yours: pccyber=# select pg_database_size('postgres');

Re: [HACKERS] pg_stat_statements

Simon Riggs <[EMAIL PROTECTED]> wrote: > I think you want to see the distribution of execution times for > particular queries without needing to log *every* execution, including > parameters. I think I understand now what you are asking for and why you > are asking for it. Yes. In many case, majo

[HACKERS] Git Repository for WITH RECURSIVE and others

Folks, With lots of help from Greg Sabino Mullane, I've set up a git repository for the WITH RECURSIVE patches on . What other patches would people like to try maintaining this way until commitfest? It looks like gitosis is a good way to grant write access to git repo

Re: [HACKERS] Git Repository for WITH RECURSIVE and others

David Fetter wrote: Folks, With lots of help from Greg Sabino Mullane, I've set up a git repository for the WITH RECURSIVE patches on . What other patches would people like to try maintaining this way until commitfest? It looks like gitosis is a good way to grant wr

Re: [HACKERS] Git Repository for WITH RECURSIVE and others

On Tue, Jun 24, 2008 at 07:09:41AM +0200, Tino Wildenhain wrote: > David Fetter wrote: >> Folks, >> >> With lots of help from Greg Sabino Mullane, I've set up a git >> repository for the WITH RECURSIVE patches on >> . >> >> What other patches would people like to try mai

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

dead easy to implement this: effectively, we just decree that the index column storage type for NAME is always CSTRING. Because the Isn't it a reason to add STORAGE option of CREATE OPERATOR CLASS to BTree? as it's done for GiST and GIN indexes. -- Teodor Sigaev

Re: [PATCHES] [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

On Mon, Jun 23, 2008 at 4:51 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > I would like to get do this without adding a new --use-statement-timeout > flag. Is anyone going to want to honor statement_timeout during > pg_dump/pg_restore? I thought we were just going to disable it. I believe so.

Re: [HACKERS] Git Repository for WITH RECURSIVE and others

Hi, From: David Fetter <[EMAIL PROTECTED]> Subject: [HACKERS] Git Repository for WITH RECURSIVE and others Date: Mon, 23 Jun 2008 21:38:11 -0700 > With lots of help from Greg Sabino Mullane, I've set up a git > repository for the WITH RECURSIVE patches on > . Thank yo

Re: [HACKERS] Dept of ugly hacks: eliminating padding space in system indexes

Mark Mielke wrote: Not that I disagree with your change, but < 5 Mbytes in 4 Gbytes of RAM for my main PostgreSQL system that I manage seems like a drop in the bucket. Even if 40% of pg_class_relname and pg_proc_proname indices was saved - we're talking about 154 Kbytes saved on both those ind