Re: [HACKERS] 9.3 Beta1 status report

2013-05-18 Thread Bruce Momjian
On Fri, May 17, 2013 at 10:54:25AM -0400, Alvaro Herrera wrote:
 Dmitriy Igrishin escribió:
 
  I've noticed a small inaccuracy:
  
  E.1.3.4 Object Manipulation
  [...]
  
  This allows C functions to be called when DDL commands are run.
  
  But according to
  http://www.postgresql.org/docs/devel/static/event-triggers.html
  not only C functions can be called in this case, but functions of
  any procedural language that includes event trigger support, or in C.
 
 That's correct -- at least plpgsql functions can be used.  I think PL/sh
 functions can, too, so using wording that leaves out other PLs would be
 inaccurate.  (No in-core languages other than plpgsql were patched, though.)

Ah, very good point I had not released.  Attached release note doc patch
applied.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml
new file mode 100644
index 519ea49..873cc78
*** a/doc/src/sgml/release-9.3.sgml
--- b/doc/src/sgml/release-9.3.sgml
***
*** 692,698 
 /para
  
 para
! This allows C functions to be called when DDL commands are run.
 /para
/listitem
  
--- 692,700 
 /para
  
 para
! This allows server-side functions written in event-enabled
! languages, e.g. C, PL/pgSQL, to be called when DDL commands
! are run.
 /para
/listitem
  

-- 
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] 9.3 Beta1 status report

2013-05-17 Thread Amit Kapila
On Friday, May 17, 2013 4:22 AM Bruce Momjian wrote:
 On Thu, May 16, 2013 at 06:49:33PM -0400, Tom Lane wrote:
  'Bruce Momjian' br...@momjian.us writes:
   On Thu, May 16, 2013 at 08:38:59PM +0530, Amit Kapila wrote:
   Reduce query processing overhead by avoiding insertion of useless
 plan nodes
   OR
   Improve performance of certain kind of queries by avoiding extra
 processing
   of doing projection
  
   This applies to queries doing identity projection (SELECT * FROM
 ...) for
   partitioned tables.
 
   Uh, that's pretty complex for our release notes, and hard to
 understand
   for most users.  All they will know is that PG is faster --- we
 don't
   document every speedup.
 
  No, but this is user-visible if they look at EXPLAIN output, and
 people
  might wonder why they were getting different results.
 
  Possibly text like
 
  Omit unnecessary Result and Limit nodes from query plans.
 
 Yes, that would be user-visible, though we rarely add details like
 that.
 What queries are faster, that users would understand?

Example:
CREATE TABLE tbl_parent (c01 numeric, c02 int); 
  
CREATE TABLE tbl_child () INHERITS(tbl_parent); 

INSERT INTO tbl_child (SELECT floor(random() * 1), n FROM
generate_series(0, 1000 - 1) n); 

SELECT * FROM tbl_parent;

Any such cases where user is selecting more number of columns from parent
table will improve a lot.

With Regards,
Amit Kapila.



-- 
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] 9.3 Beta1 status report

2013-05-17 Thread 'Bruce Momjian'
On Fri, May 17, 2013 at 10:22:59AM +0530, Amit Kapila wrote:
  Yes, that would be user-visible, though we rarely add details like
  that.
  What queries are faster, that users would understand?
 
 Example:
 CREATE TABLE tbl_parent (c01 numeric, c02 int); 
   
 CREATE TABLE tbl_child () INHERITS(tbl_parent); 
 
 INSERT INTO tbl_child (SELECT floor(random() * 1), n FROM
 generate_series(0, 1000 - 1) n); 
 
 SELECT * FROM tbl_parent;
 
 Any such cases where user is selecting more number of columns from parent
 table will improve a lot.

Sorry, I am still not seeing how this fits into the release notes.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-05-17 Thread Dmitriy Igrishin
2013/4/21 Bruce Momjian br...@momjian.us

 I am not sure if Tom shared yet, but we are planning to package 9.3
 beta1 on April 29, with a release on May 2.  Those dates might change,
 but that is the current plan.  I have completed a draft 9.3 release
 notes, which you can view here:

 http://momjian.us/pgsql_docs/release-9-3.html

 I will be working on polishing them for the next ten days, so any
 feedback, patches, or commits are welcome.  I still need to add lots of
 SGML markup.

 --
   Bruce Momjian  br...@momjian.ushttp://momjian.us
   EnterpriseDB http://enterprisedb.com

   + It's impossible for everything to be true. +


 --
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers


I've noticed a small inaccuracy:

E.1.3.4 Object Manipulation
[...]

This allows C functions to be called when DDL commands are run.

But according to
http://www.postgresql.org/docs/devel/static/event-triggers.html
not only C functions can be called in this case, but functions of
any procedural language that includes event trigger support, or in C.

-- 
// Dmitriy.


Re: [HACKERS] 9.3 Beta1 status report

2013-05-17 Thread Alvaro Herrera
Dmitriy Igrishin escribió:

 I've noticed a small inaccuracy:
 
 E.1.3.4 Object Manipulation
 [...]
 
 This allows C functions to be called when DDL commands are run.
 
 But according to
 http://www.postgresql.org/docs/devel/static/event-triggers.html
 not only C functions can be called in this case, but functions of
 any procedural language that includes event trigger support, or in C.

That's correct -- at least plpgsql functions can be used.  I think PL/sh
functions can, too, so using wording that leaves out other PLs would be
inaccurate.  (No in-core languages other than plpgsql were patched, though.)

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


-- 
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] 9.3 Beta1 status report

2013-05-16 Thread 'Bruce Momjian'
On Tue, May  7, 2013 at 10:23:48AM +0530, Amit Kapila wrote:
   2. I am not able to figure out which item of release notes cover the
  below
   feature commit
   Avoid inserting Result nodes that only compute identity projections.
   http://www.postgresql.org/message-id/E1UGCBh-0006P3-
  a...@gemulon.postgresql.org
  
  I did not think that warranted a mention in the release notes.  Was I
  wrong?
 
 This was a performance improvement for a quite usable scenario, so I thought
 it would be useful for users to know about it.
 Performance data for simple cases I have posted:
 http://www.postgresql.org/message-id/007e01ce08ff$dc0a2c60$941e8520$@kapila@
 huawei.com

I usually mention items that have a user-visible change, or are easy to
explain, or apply to most queries.  I am not sure this falls into any of
those categories.

Can you suggest some release note text for this item?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-05-16 Thread Amit Kapila
On Thursday, May 16, 2013 7:17 PM Bruce Momjian wrote:
 On Tue, May  7, 2013 at 10:23:48AM +0530, Amit Kapila wrote:
2. I am not able to figure out which item of release notes cover
 the
   below
feature commit
Avoid inserting Result nodes that only compute identity
 projections.
http://www.postgresql.org/message-id/E1UGCBh-0006P3-
   a...@gemulon.postgresql.org
  
   I did not think that warranted a mention in the release notes.  Was
 I
   wrong?
 
  This was a performance improvement for a quite usable scenario, so I
 thought
  it would be useful for users to know about it.
  Performance data for simple cases I have posted:
  http://www.postgresql.org/message-
 id/007e01ce08ff$dc0a2c60$941e8520$@kapila@
  huawei.com
 
 I usually mention items that have a user-visible change, or are easy to
 explain, or apply to most queries.  I am not sure this falls into any
 of
 those categories.
 
 Can you suggest some release note text for this item?

I can think of below text:

Reduce query processing overhead by avoiding insertion of useless plan nodes
OR
Improve performance of certain kind of queries by avoiding extra processing
of doing projection

This applies to queries doing identity projection (SELECT * FROM ...) for
partitioned tables.


With Regards,
Amit Kapila.




-- 
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] 9.3 Beta1 status report

2013-05-16 Thread 'Bruce Momjian'
On Thu, May 16, 2013 at 08:38:59PM +0530, Amit Kapila wrote:
  I usually mention items that have a user-visible change, or are easy to
  explain, or apply to most queries.  I am not sure this falls into any
  of
  those categories.
  
  Can you suggest some release note text for this item?
 
 I can think of below text:
 
 Reduce query processing overhead by avoiding insertion of useless plan nodes
 OR
 Improve performance of certain kind of queries by avoiding extra processing
 of doing projection
 
 This applies to queries doing identity projection (SELECT * FROM ...) for
 partitioned tables.

Uh, that's pretty complex for our release notes, and hard to understand
for most users.  All they will know is that PG is faster --- we don't
document every speedup.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-05-16 Thread Tom Lane
'Bruce Momjian' br...@momjian.us writes:
 On Thu, May 16, 2013 at 08:38:59PM +0530, Amit Kapila wrote:
 Reduce query processing overhead by avoiding insertion of useless plan nodes
 OR
 Improve performance of certain kind of queries by avoiding extra processing
 of doing projection
 
 This applies to queries doing identity projection (SELECT * FROM ...) for
 partitioned tables.

 Uh, that's pretty complex for our release notes, and hard to understand
 for most users.  All they will know is that PG is faster --- we don't
 document every speedup.

No, but this is user-visible if they look at EXPLAIN output, and people
might wonder why they were getting different results.

Possibly text like

Omit unnecessary Result and Limit nodes from query plans.

regards, tom lane


-- 
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] 9.3 Beta1 status report

2013-05-16 Thread 'Bruce Momjian'
On Thu, May 16, 2013 at 06:49:33PM -0400, Tom Lane wrote:
 'Bruce Momjian' br...@momjian.us writes:
  On Thu, May 16, 2013 at 08:38:59PM +0530, Amit Kapila wrote:
  Reduce query processing overhead by avoiding insertion of useless plan 
  nodes
  OR
  Improve performance of certain kind of queries by avoiding extra processing
  of doing projection
  
  This applies to queries doing identity projection (SELECT * FROM ...) for
  partitioned tables.
 
  Uh, that's pretty complex for our release notes, and hard to understand
  for most users.  All they will know is that PG is faster --- we don't
  document every speedup.
 
 No, but this is user-visible if they look at EXPLAIN output, and people
 might wonder why they were getting different results.
 
 Possibly text like
 
   Omit unnecessary Result and Limit nodes from query plans.

Yes, that would be user-visible, though we rarely add details like that.
What queries are faster, that users would understand?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-05-06 Thread Amit Kapila
On Sunday, April 21, 2013 10:32 AM Bruce Momjian wrote:
 I am not sure if Tom shared yet, but we are planning to package 9.3
 beta1 on April 29, with a release on May 2.  Those dates might change,
 but that is the current plan.  I have completed a draft 9.3 release
 notes, which you can view here:
 
   http://momjian.us/pgsql_docs/release-9-3.html
 
 I will be working on polishing them for the next ten days, so any
 feedback, patches, or commits are welcome.  I still need to add lots of
 SGML markup.

1. 
.Add wal_receiver_timeout parameter to control the WAL receiver timeout
(Amit Kapila) 
This allows more rapid detection of connection failure. No longer set
wal_receiver_status_interval? 

I don't think we need to mention anything about
wal_receiver_status_interval.

2. I am not able to figure out which item of release notes cover the below
feature commit
Avoid inserting Result nodes that only compute identity projections.
http://www.postgresql.org/message-id/e1ugcbh-0006p3...@gemulon.postgresql.or
g

With Regards,
Amit Kapila.







-- 
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] 9.3 Beta1 status report

2013-05-06 Thread 'Bruce Momjian'
On Mon, May  6, 2013 at 12:43:55PM +0530, Amit Kapila wrote:
 On Sunday, April 21, 2013 10:32 AM Bruce Momjian wrote:
  I am not sure if Tom shared yet, but we are planning to package 9.3
  beta1 on April 29, with a release on May 2.  Those dates might change,
  but that is the current plan.  I have completed a draft 9.3 release
  notes, which you can view here:
  
  http://momjian.us/pgsql_docs/release-9-3.html
  
  I will be working on polishing them for the next ten days, so any
  feedback, patches, or commits are welcome.  I still need to add lots of
  SGML markup.
 
 1. 
 .Add wal_receiver_timeout parameter to control the WAL receiver timeout
 (Amit Kapila) 
 This allows more rapid detection of connection failure. No longer set
 wal_receiver_status_interval? 
 
 I don't think we need to mention anything about
 wal_receiver_status_interval.

OK, removed.

 2. I am not able to figure out which item of release notes cover the below
 feature commit
 Avoid inserting Result nodes that only compute identity projections.
 http://www.postgresql.org/message-id/e1ugcbh-0006p3...@gemulon.postgresql.org

I did not think that warranted a mention in the release notes.  Was I
wrong?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-05-06 Thread Bruce Momjian
On Sun, May  5, 2013 at 02:16:59PM -0700, Jeff Janes wrote:
 On Thu, May 2, 2013 at 4:13 PM, Bruce Momjian br...@momjian.us wrote:
 
 On Thu, May  2, 2013 at 03:03:58PM -0700, Jeff Janes wrote:
  Some suggestions, perhaps just based on my preference for verbosity:
 
 
 para
  Add cache of local locks (Jeff Janes)
 /para
 
 para
  This speeds lock release at statement completion in transactions
  that hold many locks; it is particularly useful for pg_dump.
 /para
 
 
  I think this is equally important for restoration of dumps, if the
 restoration
  is run all in one transaction.  (Making the dump and restoring it have
 similar
  locking and unlocking patterns)
 
 Do you have proposed wording?  I can't say just dump/restore as it only
 helps with _logical_ dump and _logical_ restore, and we don't have a
 clear word for logical restore, as it could be pg_restore or piped into
 psql.  We could do:
 
 that hold many locks; it is particularly useful for pg_dump and
 restore.
 
 but restore seems very vague.
 
 
 
 Yeah, I wasn't sure about how to work that either.
 
 ...and the restore of such dumps.?

s/restore/restoring/

I like it.  Done.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-05-06 Thread Bruce Momjian
On Sun, May  5, 2013 at 06:59:28PM -0400, Andrew Dunstan wrote:
  I think this is equally important for restoration of dumps, if
 the restoration
  is run all in one transaction.  (Making the dump and restoring
 it have similar
  locking and unlocking patterns)
 
 Do you have proposed wording?  I can't say just dump/restore as it
 only
 helps with _logical_ dump and _logical_ restore, and we don't have a
 clear word for logical restore, as it could be pg_restore or piped
 into
 psql.  We could do:
 
 that hold many locks; it is particularly useful for
 pg_dump and restore.
 
 but restore seems very vague.
 
 
 
 Yeah, I wasn't sure about how to work that either.
 
 ...and the restore of such dumps.?
 
 
 s/restore/restoration/

I like that even better!  Done.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-05-06 Thread Amit Kapila
On Monday, May 06, 2013 8:17 PM Bruce Momjian wrote:
 On Mon, May  6, 2013 at 12:43:55PM +0530, Amit Kapila wrote:
  On Sunday, April 21, 2013 10:32 AM Bruce Momjian wrote:
   I am not sure if Tom shared yet, but we are planning to package 9.3
   beta1 on April 29, with a release on May 2.  Those dates might
 change,
   but that is the current plan.  I have completed a draft 9.3 release
   notes, which you can view here:
  
 http://momjian.us/pgsql_docs/release-9-3.html
  
   I will be working on polishing them for the next ten days, so any
   feedback, patches, or commits are welcome.  I still need to add
 lots of
   SGML markup.
 
  1.
  .Add wal_receiver_timeout parameter to control the WAL receiver
 timeout
  (Amit Kapila)
  This allows more rapid detection of connection failure. No longer set
  wal_receiver_status_interval?
 
  I don't think we need to mention anything about
  wal_receiver_status_interval.
 
 OK, removed.

Thanks.

  2. I am not able to figure out which item of release notes cover the
 below
  feature commit
  Avoid inserting Result nodes that only compute identity projections.
  http://www.postgresql.org/message-id/E1UGCBh-0006P3-
 a...@gemulon.postgresql.org
 
 I did not think that warranted a mention in the release notes.  Was I
 wrong?

This was a performance improvement for a quite usable scenario, so I thought
it would be useful for users to know about it.
Performance data for simple cases I have posted:
http://www.postgresql.org/message-id/007e01ce08ff$dc0a2c60$941e8520$@kapila@
huawei.com


With Regards,
Amit Kapila.



-- 
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] 9.3 Beta1 status report

2013-05-05 Thread Jeff Janes
On Thu, May 2, 2013 at 4:13 PM, Bruce Momjian br...@momjian.us wrote:

 On Thu, May  2, 2013 at 03:03:58PM -0700, Jeff Janes wrote:
  Some suggestions, perhaps just based on my preference for verbosity:
 
 
 para
  Add cache of local locks (Jeff Janes)
 /para
 
 para
  This speeds lock release at statement completion in transactions
  that hold many locks; it is particularly useful for pg_dump.
 /para
 
 
  I think this is equally important for restoration of dumps, if the
 restoration
  is run all in one transaction.  (Making the dump and restoring it have
 similar
  locking and unlocking patterns)

 Do you have proposed wording?  I can't say just dump/restore as it only
 helps with _logical_ dump and _logical_ restore, and we don't have a
 clear word for logical restore, as it could be pg_restore or piped into
 psql.  We could do:

 that hold many locks; it is particularly useful for pg_dump and
 restore.

 but restore seems very vague.



Yeah, I wasn't sure about how to work that either.

...and the restore of such dumps.?

Cheers,

Jeff


Re: [HACKERS] 9.3 Beta1 status report

2013-05-05 Thread Andrew Dunstan


On 05/05/2013 05:16 PM, Jeff Janes wrote:
On Thu, May 2, 2013 at 4:13 PM, Bruce Momjian br...@momjian.us 
mailto:br...@momjian.us wrote:


On Thu, May  2, 2013 at 03:03:58PM -0700, Jeff Janes wrote:
 Some suggestions, perhaps just based on my preference for verbosity:


para
 Add cache of local locks (Jeff Janes)
/para

para
 This speeds lock release at statement completion in
transactions
 that hold many locks; it is particularly useful for pg_dump.
/para


 I think this is equally important for restoration of dumps, if
the restoration
 is run all in one transaction.  (Making the dump and restoring
it have similar
 locking and unlocking patterns)

Do you have proposed wording?  I can't say just dump/restore as it
only
helps with _logical_ dump and _logical_ restore, and we don't have a
clear word for logical restore, as it could be pg_restore or piped
into
psql.  We could do:

that hold many locks; it is particularly useful for
pg_dump and restore.

but restore seems very vague.



Yeah, I wasn't sure about how to work that either.

...and the restore of such dumps.?



s/restore/restoration/

cheers

andrew



--
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] 9.3 Beta1 status report

2013-05-02 Thread Bruce Momjian
On Sat, Apr 27, 2013 at 05:29:51PM -0700, Josh Berkus wrote:
 Bruce,
 
 So here's my draft list of Major Enhancements for the relase notes:
 
 * Writeable Foreign Tables
 * pgsql_fdw driver for federation of PostgreSQL databases
 * Automatically updatable VIEWs
 * MATERIALIZED VIEW declaration
 * LATERAL JOINs
 * Additional JSON constructor and extractor functions
 * Indexed regular expression search
 * Disk page checksums to detect filesystem failures
 * Streaming-only remastering of replicas
 * Performance and locking improvements for Foreign Key locks
 * Parallel pg_dump for faster backups
 * Directories for configuration files
 * pg_isready database connection checker
 * COPY FREEZE for reduced IO bulk loading
 * User-defined background workers for automating database tasks
 * Recursive view declaration
 
 I note that the first one I'm leading off with actually isn't included
 in your release notes.  So please add it:
 
 Allow foreign data wrappers to accept writes
   Foreign data sources can now be written to,
   as well as read, provided that the FDW driver
   supports it.

Well, this is the text I have now, which was suggested to me:

  listitem
   para
Add a Postgres foreign data wrapper contrib module (Shigeru
Hanada, KaiGai Kohei)
   /para

   para
This foreign data wrapper allows writes;  potentially other
foreign data wrappers can now support writes.
   /para
  /listitem

Are you saying split up this into two items?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-05-02 Thread Josh Berkus

   listitem
para
 Add a Postgres foreign data wrapper contrib module (Shigeru
 Hanada, KaiGai Kohei)
/para
 
para
 This foreign data wrapper allows writes;  potentially other
 foreign data wrappers can now support writes.
/para
   /listitem
 
 Are you saying split up this into two items?

Yes, because it's two separate features.

I know Andrew plans to have a writeable Redis FDW before 9.3 is
released, for one.


-- 
Josh 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


Re: [HACKERS] 9.3 Beta1 status report

2013-05-02 Thread Bruce Momjian
On Thu, May  2, 2013 at 02:09:21PM -0700, Josh Berkus wrote:
 
listitem
 para
  Add a Postgres foreign data wrapper contrib module (Shigeru
  Hanada, KaiGai Kohei)
 /para
  
 para
  This foreign data wrapper allows writes;  potentially other
  foreign data wrappers can now support writes.
 /para
/listitem
  
  Are you saying split up this into two items?
 
 Yes, because it's two separate features.
 
 I know Andrew plans to have a writeable Redis FDW before 9.3 is
 released, for one.

OK, I have split them apart:

  listitem
   para
Allow write-enabled foreign data wrappers to support writes
(KaiGai Kohei)
   /para
  /listitem

  listitem
   para
Add a Postgres foreign data wrapper contrib module (Shigeru
Hanada)
   /para

   para
This foreign data wrapper allows writes.
   /para
  /listitem

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-05-02 Thread Bruce Momjian
On Thu, May  2, 2013 at 03:03:58PM -0700, Jeff Janes wrote:
 Some suggestions, perhaps just based on my preference for verbosity:
 
 
para
 Add cache of local locks (Jeff Janes)
/para
 
para
 This speeds lock release at statement completion in transactions
 that hold many locks; it is particularly useful for pg_dump.
/para
 
 
 I think this is equally important for restoration of dumps, if the restoration
 is run all in one transaction.  (Making the dump and restoring it have similar
 locking and unlocking patterns)

Do you have proposed wording?  I can't say just dump/restore as it only
helps with _logical_ dump and _logical_ restore, and we don't have a
clear word for logical restore, as it could be pg_restore or piped into
psql.  We could do:

that hold many locks; it is particularly useful for pg_dump and restore.

but restore seems very vague.

para
 Split pgstat file in per-database and global files (Tomas Vondra)
/para
 
para
 This reduces the statistics management read and write overhead.
/para
 
 
 Should be split pgstat file into, not split pgstat file in

That one was easy, fixed.

 Also, should it mention that the overhead reduction is particular to when a
 cluster has a large number of databases? 

Well, if you have just two databases with many tables, it still helps.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-27 Thread Josh Berkus
Bruce,

So here's my draft list of Major Enhancements for the relase notes:

* Writeable Foreign Tables
* pgsql_fdw driver for federation of PostgreSQL databases
* Automatically updatable VIEWs
* MATERIALIZED VIEW declaration
* LATERAL JOINs
* Additional JSON constructor and extractor functions
* Indexed regular expression search
* Disk page checksums to detect filesystem failures
* Streaming-only remastering of replicas
* Performance and locking improvements for Foreign Key locks
* Parallel pg_dump for faster backups
* Directories for configuration files
* pg_isready database connection checker
* COPY FREEZE for reduced IO bulk loading
* User-defined background workers for automating database tasks
* Recursive view declaration

I note that the first one I'm leading off with actually isn't included
in your release notes.  So please add it:

Allow foreign data wrappers to accept writes
Foreign data sources can now be written to,
as well as read, provided that the FDW driver
supports it.

-- 
Josh 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


Re: [HACKERS] 9.3 Beta1 status report

2013-04-25 Thread Vik Fearing
On 04/24/2013 06:34 PM, Heikki Linnakangas wrote:
 Let me clarify --- changes to our WAL binary format and source code
 changes are not really incompatibilities from a user perspective as we
 never promise to do our best to minimize such changes  --- m eaning
 the
 fact the WAL format changed is something that would be only in the
 source code section and not in the incompatibilities section  ---
 incompatibilities are related to change in user experience or
 documented-API changes.

 These guidelines makes sense, except I think the change in naming
 standard of xlog segments is important to document clearly because,
 even
 if we have not promised compatibility, people could be relying on it in
 scripts.  I think it makes sense to waste a couple of lines documenting
 this change, even if we expect the number of people to be bitten by it
 to be very low.

 Right. Kevin mentioned he had a script that knew about the numbering:
 http://www.postgresql.org/message-id/4fd09b5e022500048...@gw.wicourts.gov.


We also have scripts that know about the missing FF.  How slim are the
chances of having pg_xlogdump output the version of the wal file for
9.3?  I know we're right on top of the deadline, but that tool and this
change are both new to 9.3. That way our scripts could know if a file is
missing or not.

I talked about this briefly with Andres on IRC and he says a patch to do
this would be trivial.

Thoughts?


-- 
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] 9.3 Beta1 status report

2013-04-25 Thread Heikki Linnakangas

On 25.04.2013 12:43, Vik Fearing wrote:

On 04/24/2013 06:34 PM, Heikki Linnakangas wrote:

Let me clarify --- changes to our WAL binary format and source code
changes are not really incompatibilities from a user perspective as we
never promise to do our best to minimize such changes  --- m eaning
the
fact the WAL format changed is something that would be only in the
source code section and not in the incompatibilities section  ---
incompatibilities are related to change in user experience or
documented-API changes.


These guidelines makes sense, except I think the change in naming
standard of xlog segments is important to document clearly because,
even
if we have not promised compatibility, people could be relying on it in
scripts.  I think it makes sense to waste a couple of lines documenting
this change, even if we expect the number of people to be bitten by it
to be very low.


Right. Kevin mentioned he had a script that knew about the numbering:
http://www.postgresql.org/message-id/4fd09b5e022500048...@gw.wicourts.gov.


We also have scripts that know about the missing FF.  How slim are the
chances of having pg_xlogdump output the version of the wal file for
9.3?  I know we're right on top of the deadline, but that tool and this
change are both new to 9.3. That way our scripts could know if a file is
missing or not.

I talked about this briefly with Andres on IRC and he says a patch to do
this would be trivial.


Seems reasonable. Patches are welcome :-). We're not going to guarantee 
that pg_xlogdump works across versions, but printing out the version 
that generated the file seems easy enough. If your script has access to 
the data directory, you could also easily check PG_VERSION.


- Heikki


--
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] 9.3 Beta1 status report

2013-04-24 Thread Heikki Linnakangas

On 24.04.2013 06:22, Bruce Momjian wrote:

On Tue, Apr 23, 2013 at 06:56:34PM -0300, Alvaro Herrera wrote:

Bruce Momjian wrote:

On Tue, Apr 23, 2013 at 05:04:15PM -0400, Bruce Momjian wrote:

Do we usually repeat the changes listed in the backwards
compatibility section later, in the Changes section? If not, then
instead of the first two items above, let's just have these in the
backwards-compatibility section:


We do not repeat the incompatibile items later in release notes.  I have
added some of your text to one of the items, and added a mention that
tooling will need adjustment.  Please check the post-commit version and
let me know about adjustments.


Let me clarify --- changes to our WAL binary format and source code
changes are not really incompatibilities from a user perspective as we
never promise to do our best to minimize such changes  --- m eaning the
fact the WAL format changed is something that would be only in the
source code section and not in the incompatibilities section  ---
incompatibilities are related to change in user experience or
documented-API changes.


These guidelines makes sense, except I think the change in naming
standard of xlog segments is important to document clearly because, even
if we have not promised compatibility, people could be relying on it in
scripts.  I think it makes sense to waste a couple of lines documenting
this change, even if we expect the number of people to be bitten by it
to be very low.


Right. Kevin mentioned he had a script that knew about the numbering: 
http://www.postgresql.org/message-id/4fd09b5e022500048...@gw.wicourts.gov.



Agreed.  Here is the new text:

 Store WAL in a continuous stream, rather than skipping the last
 16MB segment every 4GB (Heikki Linnakangas)  BACKWARD COMPATIBLE BREAK

 Previously, WAL files ending in FF were not used.  If you have
 WAL backup or restore scripts that took that skipping into account,
 they need to be adjusted.


Looks good, thanks!

- Heikki


--
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] 9.3 Beta1 status report

2013-04-23 Thread Dean Rasheed
On 21 April 2013 06:02, Bruce Momjian br...@momjian.us wrote:
 I am not sure if Tom shared yet, but we are planning to package 9.3
 beta1 on April 29, with a release on May 2.  Those dates might change,
 but that is the current plan.  I have completed a draft 9.3 release
 notes, which you can view here:

 http://momjian.us/pgsql_docs/release-9-3.html

 I will be working on polishing them for the next ten days, so any
 feedback, patches, or commits are welcome.  I still need to add lots of
 SGML markup.


E.1.3.4.4. VIEWs:

* Make simple views auto-updatable (Dean Rasheed)

  INSTEAD rules are still available for complex views.


I think this should refer to INSTEAD OF triggers for complex views,
since that is now the recommended way to implement updatable views.

I think it should also expand a little on what simple means in this
context, without going into all the gory details, and mention that
there is a behaviour change. So perhaps something like this for the
second paragraph:

Simple views that select some or all columns from a single base table
are now updatable by default. More complex views can be made updatable
using INSTEAD OF triggers or INSTEAD rules.

Regards,
Dean


-- 
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] 9.3 Beta1 status report

2013-04-23 Thread Heikki Linnakangas

On 22.04.2013 23:06, Bruce Momjian wrote:

On Mon, Apr 22, 2013 at 10:11:48PM +0300, Heikki Linnakangas wrote:

E.1.3.2.1. Write-Ahead Log (WAL)

Store WAL in a continuous stream, rather than skipping the last 16MB 
segment every 4GB (Heikki Linnakangas) BACKWARD COMPATIBLE BREAK

Restructure WAL files to better handle timeline changes during recovery 
(Heikki Linnakangas)

Restructure WAL files to use a more compact storage format (Heikki 
Linnakangas)


Can you clarify which commits these came from? The first one is
clear (dfda6eba), and I think the 3rd covers commits 20ba5ca6 and
061e7efb1. But what is that second entry?


Frankly, I found the WAL and timeline commits all over the place and
could hardly make sense of it.  I tried to collapse entries into
meaningful items, but I need help.  Can you suggest changes?


Ok:

* Don't skip the last 16 MB WAL segment every 4GB, with filename ending 
in FF (Heikki Linnakangas) BACKWARD COMPATIBLE BREAK


* Change WAL record format, allowing the record header to be split 
across pages. The new format is slightly more compact. (Heikki Linnakangas)


In Source Code section:

* Use a 64-bit integer to represent WAL positions (XLogRecPtr), instead 
of two 32-bit integers. (Heikki Linnakangas)



Do we usually repeat the changes listed in the backwards compatibility 
section later, in the Changes section? If not, then instead of the 
first two items above, let's just have these in the 
backwards-compatibility section:


* The WAL file numbering has changed to not skip WAL files ending with FF.

  If you have e.g backup / restore scripts that took the skipping into
  account, they need to be adjusted.

* The WAL format has changed.

  Any external tools that read the WAL files need to be adjusted to
  understand the new format. The new xlogreader facility helps
  writing such tools.

- Heikki


--
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] 9.3 Beta1 status report

2013-04-23 Thread Bruce Momjian
On Tue, Apr 23, 2013 at 10:12:58AM +0100, Dean Rasheed wrote:
 On 21 April 2013 06:02, Bruce Momjian br...@momjian.us wrote:
  I am not sure if Tom shared yet, but we are planning to package 9.3
  beta1 on April 29, with a release on May 2.  Those dates might change,
  but that is the current plan.  I have completed a draft 9.3 release
  notes, which you can view here:
 
  http://momjian.us/pgsql_docs/release-9-3.html
 
  I will be working on polishing them for the next ten days, so any
  feedback, patches, or commits are welcome.  I still need to add lots of
  SGML markup.
 
 
 E.1.3.4.4. VIEWs:
 
 * Make simple views auto-updatable (Dean Rasheed)
 
   INSTEAD rules are still available for complex views.
 
 
 I think this should refer to INSTEAD OF triggers for complex views,
 since that is now the recommended way to implement updatable views.
 
 I think it should also expand a little on what simple means in this
 context, without going into all the gory details, and mention that
 there is a behaviour change. So perhaps something like this for the
 second paragraph:
 
 Simple views that select some or all columns from a single base table
 are now updatable by default. More complex views can be made updatable
 using INSTEAD OF triggers or INSTEAD rules.

I like it!   Done.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-23 Thread Bruce Momjian
On Tue, Apr 23, 2013 at 05:36:03PM +0800, Jov wrote:
 E.1.3.1.4:
 
 Improve performance of the CREATE TABLE ... ON COMMIT DELETE ROWS clause by
 only issuing delete if the temporary table was accessed (Heikki Linnakangas)
 
 should be:
              CREATE TEMP TABLE ... ON COMMIT DELETE ROWS
 or
            CREATE { TEMPORARY | TEMP } TABLE ... ON COMMIT DELETE ROWS
 
 because there is no syntax for CREATE TABLE ... ON COMMIT DELETE ROWS

Oh, good point.  Fixed.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-23 Thread Erikjan Rijkers
I just spotted some more small stuff:

s/IF NOT EXIST /IF NOT EXISTS /g   # 2 x


It actually had me doubting, but yes that -S should be there...


Thanks,

Erik Rijkers



-- 
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] 9.3 Beta1 status report

2013-04-23 Thread Bruce Momjian
On Tue, Apr 23, 2013 at 02:25:08PM +0300, Heikki Linnakangas wrote:
 On 22.04.2013 23:06, Bruce Momjian wrote:
 On Mon, Apr 22, 2013 at 10:11:48PM +0300, Heikki Linnakangas wrote:
 E.1.3.2.1. Write-Ahead Log (WAL)
 
 Store WAL in a continuous stream, rather than skipping the last 16MB 
  segment every 4GB (Heikki Linnakangas) BACKWARD COMPATIBLE BREAK
 
 Restructure WAL files to better handle timeline changes during 
  recovery (Heikki Linnakangas)
 
 Restructure WAL files to use a more compact storage format (Heikki 
  Linnakangas)
 
 Can you clarify which commits these came from? The first one is
 clear (dfda6eba), and I think the 3rd covers commits 20ba5ca6 and
 061e7efb1. But what is that second entry?
 
 Frankly, I found the WAL and timeline commits all over the place and
 could hardly make sense of it.  I tried to collapse entries into
 meaningful items, but I need help.  Can you suggest changes?
 
 Ok:
 
 * Don't skip the last 16 MB WAL segment every 4GB, with filename
 ending in FF (Heikki Linnakangas) BACKWARD COMPATIBLE BREAK

Uh, I am unclear why this is better than the original text.  We don't
normally explain things like WAL file patterns in the release notes.
 
 * Change WAL record format, allowing the record header to be split
 across pages. The new format is slightly more compact. (Heikki
 Linnakangas)

Done.

 In Source Code section:
 
 * Use a 64-bit integer to represent WAL positions (XLogRecPtr),
 instead of two 32-bit integers. (Heikki Linnakangas)

Added.
 
 Do we usually repeat the changes listed in the backwards
 compatibility section later, in the Changes section? If not, then
 instead of the first two items above, let's just have these in the
 backwards-compatibility section:

We do not repeat the incompatibile items later in release notes.  I have
added some of your text to one of the items, and added a mention that
tooling will need adjustment.  Please check the post-commit version and
let me know about adjustments.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-23 Thread Bruce Momjian
On Tue, Apr 23, 2013 at 11:00:31PM +0200, Erikjan Rijkers wrote:
 I just spotted some more small stuff:
 
 s/IF NOT EXIST /IF NOT EXISTS /g   # 2 x
 
 
 It actually had me doubting, but yes that -S should be there...

Fixed, thanks.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-23 Thread Bruce Momjian
On Tue, Apr 23, 2013 at 05:04:15PM -0400, Bruce Momjian wrote:
  Do we usually repeat the changes listed in the backwards
  compatibility section later, in the Changes section? If not, then
  instead of the first two items above, let's just have these in the
  backwards-compatibility section:
 
 We do not repeat the incompatibile items later in release notes.  I have
 added some of your text to one of the items, and added a mention that
 tooling will need adjustment.  Please check the post-commit version and
 let me know about adjustments.

Let me clarify --- changes to our WAL binary format and source code
changes are not really incompatibilities from a user perspective as we
never promise to do our best to minimize such changes  --- m eaning the
fact the WAL format changed is something that would be only in the
source code section and not in the incompatibilities section  ---
incompatibilities are related to change in user experience or
documented-API changes.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-23 Thread Alvaro Herrera
Bruce Momjian wrote:
 On Tue, Apr 23, 2013 at 05:04:15PM -0400, Bruce Momjian wrote:
   Do we usually repeat the changes listed in the backwards
   compatibility section later, in the Changes section? If not, then
   instead of the first two items above, let's just have these in the
   backwards-compatibility section:
  
  We do not repeat the incompatibile items later in release notes.  I have
  added some of your text to one of the items, and added a mention that
  tooling will need adjustment.  Please check the post-commit version and
  let me know about adjustments.
 
 Let me clarify --- changes to our WAL binary format and source code
 changes are not really incompatibilities from a user perspective as we
 never promise to do our best to minimize such changes  --- m eaning the
 fact the WAL format changed is something that would be only in the
 source code section and not in the incompatibilities section  ---
 incompatibilities are related to change in user experience or
 documented-API changes.

These guidelines makes sense, except I think the change in naming
standard of xlog segments is important to document clearly because, even
if we have not promised compatibility, people could be relying on it in
scripts.  I think it makes sense to waste a couple of lines documenting
this change, even if we expect the number of people to be bitten by it
to be very low.

Unrelated: I think this item
  Add configuration variable lock_timeout to limit lock wait duration
  (Zoltán Böszörményi)
should go in the locking section.  What's of interest here is the new
feature to set maximum lock waits.  The fact that this is done using a
configuration variable is not that important.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


-- 
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] 9.3 Beta1 status report

2013-04-23 Thread Bruce Momjian
On Tue, Apr 23, 2013 at 06:56:34PM -0300, Alvaro Herrera wrote:
 Bruce Momjian wrote:
  On Tue, Apr 23, 2013 at 05:04:15PM -0400, Bruce Momjian wrote:
Do we usually repeat the changes listed in the backwards
compatibility section later, in the Changes section? If not, then
instead of the first two items above, let's just have these in the
backwards-compatibility section:
   
   We do not repeat the incompatibile items later in release notes.  I have
   added some of your text to one of the items, and added a mention that
   tooling will need adjustment.  Please check the post-commit version and
   let me know about adjustments.
  
  Let me clarify --- changes to our WAL binary format and source code
  changes are not really incompatibilities from a user perspective as we
  never promise to do our best to minimize such changes  --- m eaning the
  fact the WAL format changed is something that would be only in the
  source code section and not in the incompatibilities section  ---
  incompatibilities are related to change in user experience or
  documented-API changes.
 
 These guidelines makes sense, except I think the change in naming
 standard of xlog segments is important to document clearly because, even
 if we have not promised compatibility, people could be relying on it in
 scripts.  I think it makes sense to waste a couple of lines documenting
 this change, even if we expect the number of people to be bitten by it
 to be very low.

Agreed.  Here is the new text:

Store WAL in a continuous stream, rather than skipping the last
16MB segment every 4GB (Heikki Linnakangas)  BACKWARD COMPATIBLE BREAK

Previously, WAL files ending in FF were not used.  If you have
WAL backup or restore scripts that took that skipping into account,
they need to be adjusted.

 Unrelated: I think this item
   Add configuration variable lock_timeout to limit lock wait duration
   (Zoltán Böszörményi)
 should go in the locking section.  What's of interest here is the new
 feature to set maximum lock waits.  The fact that this is done using a
 configuration variable is not that important.

Agreed.  Moved.  Thanks.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-22 Thread Boszormenyi Zoltan

2013-04-21 15:10 keltezéssel, Bruce Momjian írta:

On Sun, Apr 21, 2013 at 09:34:10AM +0200, Boszormenyi Zoltan wrote:

2013-04-21 07:02 keltezéssel, Bruce Momjian írta:

I am not sure if Tom shared yet, but we are planning to package 9.3
beta1 on April 29, with a release on May 2.  Those dates might change,
but that is the current plan.  I have completed a draft 9.3 release
notes, which you can view here:

http://momjian.us/pgsql_docs/release-9-3.html

I will be working on polishing them for the next ten days, so any
feedback, patches, or commits are welcome.  I still need to add lots of
SGML markup.

How comes Álvaro's name comes out right in your page but not at
http://www.postgresql.org/docs/devel/static/release-9-3.html ?

Anyway, I attached a patch to fix my name in your page using markups.

Thanks, applied.


Thank you.


   I had not yet gotten to doing the SGML markup for
non-ASCII characters.




--
--
Zoltán Böszörményi
Cybertec Schönig  Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
 http://www.postgresql.at/



--
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] 9.3 Beta1 status report

2013-04-22 Thread Alvaro Herrera
Bruce Momjian wrote:
 I am not sure if Tom shared yet, but we are planning to package 9.3
 beta1 on April 29, with a release on May 2.  Those dates might change,
 but that is the current plan.  I have completed a draft 9.3 release
 notes, which you can view here:
 
   http://momjian.us/pgsql_docs/release-9-3.html
 
 I will be working on polishing them for the next ten days, so any
 feedback, patches, or commits are welcome.  I still need to add lots of
 SGML markup.

Can you please clarify the policy on attaching people's names to items?

This item
  Have DROP OWNED only remove user-matching GRANTs on shared objects, e.g.
  databases, tablespaces (Álvaro Herrera)
was a backpatched bugfix; I don't think it should be listed.


This item
  Throw an error if expiring tuple is again updated or deleted (Kevin
  Grittner) KEEP?

not only needs to be kept, but is also a backward-incompatible change,
so I think it warrants a more verbose explanation.


This item
  Improve the ability to detect indexable prefixes in regular
  expressions (Tom Lane)
I'm not really sure about it.  Isn't it about the new pg_trgm code to
support regex indexes?  I think they either belong together, or perhaps
the one in optimizer shouldn't be listed.

This item
  Implement a generic binary heap and use it for Merge-Append operations
  (Abhijit Menon-Sen)

A generic binary heap was implemented; but merge-append was already
using their own binary heap.  So this is not a performance optimization.
I think the item should be moved down to the source code section.

There's an extra double quote here:
  Allow in-memory sorts to use their full memory allocation (Jeff Janes)


This item:
  Allow heap-only tuple updates on system tables (Andres Freund)
was a bug fix; item should be removed.


Shouldn't this one
  Add function to report the size of the GIN pending index insertion
  list (Fujii Masao)
be in the additional modules section?


In this item
  Add support to event triggers (Dimitri Fontaine, Tom Lane)
I am not sure why you list Tom.  I think Robert should be listed
instead.


In this this
  Internally store default foreign key matches (non-FULL, non-PARTIAL) as
  simple (Tom Lane)
there is something funny going on with  chars around unspecified.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


-- 
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] 9.3 Beta1 status report

2013-04-22 Thread Bruce Momjian
On Mon, Apr 22, 2013 at 01:54:03PM -0300, Alvaro Herrera wrote:
 Bruce Momjian wrote:
  I am not sure if Tom shared yet, but we are planning to package 9.3
  beta1 on April 29, with a release on May 2.  Those dates might change,
  but that is the current plan.  I have completed a draft 9.3 release
  notes, which you can view here:
  
  http://momjian.us/pgsql_docs/release-9-3.html
  
  I will be working on polishing them for the next ten days, so any
  feedback, patches, or commits are welcome.  I still need to add lots of
  SGML markup.
 
 Can you please clarify the policy on attaching people's names to items?

Well, I just pull them from the commit message, of it no one is
mentioned in the commit message, I use the committer's name.

 This item
   Have DROP OWNED only remove user-matching GRANTs on shared objects, e.g.
   databases, tablespaces (Álvaro Herrera)
 was a backpatched bugfix; I don't think it should be listed.

OK, removed.  I now see there was a backpatch mention in the commit
messsage.

 This item
   Throw an error if expiring tuple is again updated or deleted (Kevin
   Grittner) KEEP?
 
 not only needs to be kept, but is also a backward-incompatible change,
 so I think it warrants a more verbose explanation.

OK, I don't understand myself, so I will need details.  I marked it as
backward-incompatible.

 This item
   Improve the ability to detect indexable prefixes in regular
   expressions (Tom Lane)
 I'm not really sure about it.  Isn't it about the new pg_trgm code to
 support regex indexes?  I think they either belong together, or perhaps
 the one in optimizer shouldn't be listed.

I have no idea.  I certainly see it affecting more than pg_trgm;  I see
backend regression test additions with the patch, 
628cbb50ba80c83917b07a7609ddec12cda172d0.

 This item
   Implement a generic binary heap and use it for Merge-Append operations
   (Abhijit Menon-Sen)
 
 A generic binary heap was implemented; but merge-append was already
 using their own binary heap.  So this is not a performance optimization.
 I think the item should be moved down to the source code section.

OK.


 There's an extra double quote here:
   Allow in-memory sorts to use their full memory allocation (Jeff Janes)

Fixed.
 
 This item:
   Allow heap-only tuple updates on system tables (Andres Freund)
 was a bug fix; item should be removed.

OK.

 Shouldn't this one
   Add function to report the size of the GIN pending index insertion
   list (Fujii Masao)
 be in the additional modules section?

Yes, moved.

 In this item
   Add support to event triggers (Dimitri Fontaine, Tom Lane)
 I am not sure why you list Tom.  I think Robert should be listed
 instead.

Tom did a massive fix/cleanup of that code.  I have added Robert.

 In this this
   Internally store default foreign key matches (non-FULL, non-PARTIAL) as
   simple (Tom Lane)
 there is something funny going on with  chars around unspecified.

Fixed, and applied.

Thanks!

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-22 Thread Heikki Linnakangas

Allow tooling like pg_receivexlog to run on computers with different 
architectures (Heikki Linnakangas)


This probably should be mentioned in the backwards-compatibility 
section. Any 3rd party tools that speak the streaming replication 
protocol are affected.



E.1.3.2.1. Write-Ahead Log (WAL)

Store WAL in a continuous stream, rather than skipping the last 16MB 
segment every 4GB (Heikki Linnakangas) BACKWARD COMPATIBLE BREAK

Restructure WAL files to better handle timeline changes during recovery 
(Heikki Linnakangas)

Restructure WAL files to use a more compact storage format (Heikki 
Linnakangas)


Can you clarify which commits these came from? The first one is clear 
(dfda6eba), and I think the 3rd covers commits 20ba5ca6 and 061e7efb1. 
But what is that second entry?


- Heikki


--
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] 9.3 Beta1 status report

2013-04-22 Thread Robert Haas
On Mon, Apr 22, 2013 at 2:33 PM, Bruce Momjian br...@momjian.us wrote:
 In this item
   Add support to event triggers (Dimitri Fontaine, Tom Lane)
 I am not sure why you list Tom.  I think Robert should be listed
 instead.

 Tom did a massive fix/cleanup of that code.  I have added Robert.

I do not think that is true.  To what commit IDs are you referring?  I
think this item should credit Dimitri, myself, and Alvaro, probably in
that order.  The only commit by Tom to event_triggers.c is
cd3413ec3683918c9cb9cfb39ae5b2c32f231e8b, which is hardly a massive
fix/cleanup.

--
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.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 9.3 Beta1 status report

2013-04-22 Thread Alvaro Herrera
Bruce Momjian wrote:
 On Mon, Apr 22, 2013 at 01:54:03PM -0300, Alvaro Herrera wrote:
  Bruce Momjian wrote:
   I am not sure if Tom shared yet, but we are planning to package 9.3
   beta1 on April 29, with a release on May 2.  Those dates might change,
   but that is the current plan.  I have completed a draft 9.3 release
   notes, which you can view here:
   
 http://momjian.us/pgsql_docs/release-9-3.html
   
   I will be working on polishing them for the next ten days, so any
   feedback, patches, or commits are welcome.  I still need to add lots of
   SGML markup.
  
  Can you please clarify the policy on attaching people's names to items?
 
 Well, I just pull them from the commit message, of it no one is
 mentioned in the commit message, I use the committer's name.

Hm, I listed code authors in roughly chronological order in 0ac5ad51
(fklocks).  I think that patch should list me, Noah, Andres, Alex,
Marti.

  This item
Improve the ability to detect indexable prefixes in regular
expressions (Tom Lane)
  I'm not really sure about it.  Isn't it about the new pg_trgm code to
  support regex indexes?  I think they either belong together, or perhaps
  the one in optimizer shouldn't be listed.
 
 I have no idea.  I certainly see it affecting more than pg_trgm;  I see
 backend regression test additions with the patch, 
 628cbb50ba80c83917b07a7609ddec12cda172d0.

Ah, yeah, it's unrelated to pg_trgm indexing.  It's a (backpatched) bug
fix, though.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


-- 
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] 9.3 Beta1 status report

2013-04-22 Thread Bruce Momjian
On Mon, Apr 22, 2013 at 03:19:36PM -0400, Robert Haas wrote:
 On Mon, Apr 22, 2013 at 2:33 PM, Bruce Momjian br...@momjian.us wrote:
  In this item
Add support to event triggers (Dimitri Fontaine, Tom Lane)
  I am not sure why you list Tom.  I think Robert should be listed
  instead.
 
  Tom did a massive fix/cleanup of that code.  I have added Robert.
 
 I do not think that is true.  To what commit IDs are you referring?  I
 think this item should credit Dimitri, myself, and Alvaro, probably in
 that order.  The only commit by Tom to event_triggers.c is
 cd3413ec3683918c9cb9cfb39ae5b2c32f231e8b, which is hardly a massive
 fix/cleanup.

OK, changed.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-22 Thread Bruce Momjian
On Mon, Apr 22, 2013 at 04:48:58PM -0300, Alvaro Herrera wrote:
 Bruce Momjian wrote:
  On Mon, Apr 22, 2013 at 01:54:03PM -0300, Alvaro Herrera wrote:
   Bruce Momjian wrote:
I am not sure if Tom shared yet, but we are planning to package 9.3
beta1 on April 29, with a release on May 2.  Those dates might change,
but that is the current plan.  I have completed a draft 9.3 release
notes, which you can view here:

http://momjian.us/pgsql_docs/release-9-3.html

I will be working on polishing them for the next ten days, so any
feedback, patches, or commits are welcome.  I still need to add lots of
SGML markup.
   
   Can you please clarify the policy on attaching people's names to items?
  
  Well, I just pull them from the commit message, of it no one is
  mentioned in the commit message, I use the committer's name.
 
 Hm, I listed code authors in roughly chronological order in 0ac5ad51
 (fklocks).  I think that patch should list me, Noah, Andres, Alex,
 Marti.

OK, I have now listed them in the order you specified.

   This item
 Improve the ability to detect indexable prefixes in regular
 expressions (Tom Lane)
   I'm not really sure about it.  Isn't it about the new pg_trgm code to
   support regex indexes?  I think they either belong together, or perhaps
   the one in optimizer shouldn't be listed.
  
  I have no idea.  I certainly see it affecting more than pg_trgm;  I see
  backend regression test additions with the patch, 
  628cbb50ba80c83917b07a7609ddec12cda172d0.
 
 Ah, yeah, it's unrelated to pg_trgm indexing.  It's a (backpatched) bug
 fix, though.

OK, removed.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-22 Thread Bruce Momjian
On Mon, Apr 22, 2013 at 10:11:48PM +0300, Heikki Linnakangas wrote:
 Allow tooling like pg_receivexlog to run on computers with different 
 architectures (Heikki Linnakangas)
 
 This probably should be mentioned in the backwards-compatibility
 section. Any 3rd party tools that speak the streaming replication
 protocol are affected.
 
 E.1.3.2.1. Write-Ahead Log (WAL)
 
 Store WAL in a continuous stream, rather than skipping the last 16MB 
  segment every 4GB (Heikki Linnakangas) BACKWARD COMPATIBLE BREAK
 
 Restructure WAL files to better handle timeline changes during recovery 
  (Heikki Linnakangas)
 
 Restructure WAL files to use a more compact storage format (Heikki 
  Linnakangas)
 
 Can you clarify which commits these came from? The first one is
 clear (dfda6eba), and I think the 3rd covers commits 20ba5ca6 and
 061e7efb1. But what is that second entry?

Frankly, I found the WAL and timeline commits all over the place and
could hardly make sense of it.  I tried to collapse entries into
meaningful items, but I need help.  Can you suggest changes?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-22 Thread Alvaro Herrera

Some more diacritics ..

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services
diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml
index 7c46bd3..68d04a7 100644
--- a/doc/src/sgml/release-9.3.sgml
+++ b/doc/src/sgml/release-9.3.sgml
@@ -336,7 +336,7 @@
   listitem
para
 Allow the postmaster to listen on multiple Unix-domain sockets
-(Honza Horak)
+(Honza Horaacute;k)
/para
 
para
@@ -1064,7 +1064,7 @@
   listitem
para
 Add libpq function PQconninfo() to return connection information
-(Zoltan Boszormenyi, Magnus Hagander)
+(Zoltaacute;n Bouml;szouml;rmeacute;nyi, Magnus Hagander)
/para
   /listitem
 

-- 
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] 9.3 Beta1 status report

2013-04-22 Thread Bruce Momjian
On Mon, Apr 22, 2013 at 05:53:43PM -0300, Alvaro Herrera wrote:
 
 Some more diacritics ..

Thanks, applied.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-21 Thread Boszormenyi Zoltan

2013-04-21 07:02 keltezéssel, Bruce Momjian írta:

I am not sure if Tom shared yet, but we are planning to package 9.3
beta1 on April 29, with a release on May 2.  Those dates might change,
but that is the current plan.  I have completed a draft 9.3 release
notes, which you can view here:

http://momjian.us/pgsql_docs/release-9-3.html

I will be working on polishing them for the next ten days, so any
feedback, patches, or commits are welcome.  I still need to add lots of
SGML markup.


How comes Álvaro's name comes out right in your page but not at
http://www.postgresql.org/docs/devel/static/release-9-3.html ?

Anyway, I attached a patch to fix my name in your page using markups.

Thanks,
Zoltán Böszörményi


--
--
Zoltán Böszörményi
Cybertec Schönig  Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
 http://www.postgresql.at/

diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml
index 76ba128..2927272 100644
--- a/doc/src/sgml/release-9.3.sgml
+++ b/doc/src/sgml/release-9.3.sgml
@@ -367,7 +367,7 @@
   listitem
para
 Add configuration variable lock_timeout to limit lock wait duration
-(Zoltán Böszörményi)
+(Zoltaacute;n Bouml;szouml;rmeacute;nyi)
/para
   /listitem
 
@@ -488,7 +488,7 @@
   listitem
para
 Have pg_basebackup --write-recovery-conf output a minimal
-recovery.conf (Zoltan Boszormenyi, Magnus Hagander)
+recovery.conf (Zoltaacute;n Bouml;szouml;rmeacute;nyi, Magnus Hagander)
/para
 
para
@@ -1357,7 +1357,7 @@
 
   listitem
para
-Create a centralized timeout API (Zoltán Böszörményi)
+Create a centralized timeout API (Zoltaacute;n Bouml;szouml;rmeacute;nyi)
/para
   /listitem
 

-- 
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] 9.3 Beta1 status report

2013-04-21 Thread Alexander Korotkov
On Sun, Apr 21, 2013 at 9:02 AM, Bruce Momjian br...@momjian.us wrote:

 I am not sure if Tom shared yet, but we are planning to package 9.3
 beta1 on April 29, with a release on May 2.  Those dates might change,
 but that is the current plan.  I have completed a draft 9.3 release
 notes, which you can view here:

 http://momjian.us/pgsql_docs/release-9-3.html

 I will be working on polishing them for the next ten days, so any
 feedback, patches, or commits are welcome.  I still need to add lots of
 SGML markup


* Collect and use histograms of lower and upper bounds for range types
(Alexander Korotkov)

Actually, we also collect histogram of range lengths. Probably, we can
rephrase it more generally, like Collect and use special statistics for
range types.

--
With best regards,
Alexander Korotkov.


Re: [HACKERS] 9.3 Beta1 status report

2013-04-21 Thread Andres Freund
On 2013-04-20 22:36:32 -0700, Peter Geoghegan wrote:
 On Sat, Apr 20, 2013 at 10:02 PM, Bruce Momjian br...@momjian.us wrote:
  I will be working on polishing them for the next ten days, so any
  feedback, patches, or commits are welcome.  I still need to add lots of
  SGML markup.
 
 I've noticed a few things:
 
 * Allow heap-only tuple updates on system tables (Andres Freund)
 
 Didn't Andres just fix a bug wherein HOT updates usually wouldn't
 occur on system tables following the commit of the foreign key locks
 patch?

Yes, that definitely was a bugfix for a HEAD only feature.

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services


-- 
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] 9.3 Beta1 status report

2013-04-21 Thread Bruce Momjian
On Sat, Apr 20, 2013 at 10:36:32PM -0700, Peter Geoghegan wrote:
 * Improve grouping of sessions waiting for commit_delay (Peter Geoghegan)
 
 I think this should be under General Performance. It's definitely a
 performance feature.

OK, moved.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-21 Thread Bruce Momjian
On Sun, Apr 21, 2013 at 09:34:10AM +0200, Boszormenyi Zoltan wrote:
 2013-04-21 07:02 keltezéssel, Bruce Momjian írta:
 I am not sure if Tom shared yet, but we are planning to package 9.3
 beta1 on April 29, with a release on May 2.  Those dates might change,
 but that is the current plan.  I have completed a draft 9.3 release
 notes, which you can view here:
 
  http://momjian.us/pgsql_docs/release-9-3.html
 
 I will be working on polishing them for the next ten days, so any
 feedback, patches, or commits are welcome.  I still need to add lots of
 SGML markup.
 
 How comes Álvaro's name comes out right in your page but not at
 http://www.postgresql.org/docs/devel/static/release-9-3.html ?
 
 Anyway, I attached a patch to fix my name in your page using markups.

Thanks, applied.  I had not yet gotten to doing the SGML markup for
non-ASCII characters.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-21 Thread Bruce Momjian
On Sun, Apr 21, 2013 at 02:45:42PM +0400, Alexander Korotkov wrote:
 On Sun, Apr 21, 2013 at 9:02 AM, Bruce Momjian br...@momjian.us wrote:
 
 I am not sure if Tom shared yet, but we are planning to package 9.3
 beta1 on April 29, with a release on May 2.  Those dates might change,
 but that is the current plan.  I have completed a draft 9.3 release
 notes, which you can view here:
 
 http://momjian.us/pgsql_docs/release-9-3.html
 
 I will be working on polishing them for the next ten days, so any
 feedback, patches, or commits are welcome.  I still need to add lots of
 SGML markup
 
 
 * Collect and use histograms of lower and upper bounds for range types
 (Alexander Korotkov)
 
 Actually, we also collect histogram of range lengths. Probably, we can 
 rephrase
 it more generally, like Collect and use special statistics for range types.

Done, thanks.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
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] 9.3 Beta1 status report

2013-04-21 Thread Josh Berkus
Bruce,

I don't see parallel pg_dump in the release notes.  I thought that got
committed?

Anyway, see the pgsql-advocacy list for a longish discussion about what
we should consider the major fetures for 9.3.


-- 
Josh 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


Re: [HACKERS] 9.3 Beta1 status report

2013-04-21 Thread Andres Freund
On 2013-04-21 14:50:07 -0700, Josh Berkus wrote:
 Bruce,
 
 I don't see parallel pg_dump in the release notes.  I thought that got
 committed?


E.1.3.8.2. pg_dump:
Add pg_dump --jobs to dump in parallel when using directory output
format (Joachim Wieland)

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services


-- 
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] 9.3 Beta1 status report

2013-04-20 Thread Peter Geoghegan
On Sat, Apr 20, 2013 at 10:02 PM, Bruce Momjian br...@momjian.us wrote:
 I will be working on polishing them for the next ten days, so any
 feedback, patches, or commits are welcome.  I still need to add lots of
 SGML markup.

I've noticed a few things:

* Allow heap-only tuple updates on system tables (Andres Freund)

Didn't Andres just fix a bug wherein HOT updates usually wouldn't
occur on system tables following the commit of the foreign key locks
patch? While HOT's development occurred at a time before I followed
pgsql-hackers, I seem to recall someone telling me that Tom insisted
upon HOT working with system catalogs specifically because if it
wasn't good enough to work there, it wasn't good enough to work
anywhere, or something like that. I guess the source of the confusion
is specifically that at one point HOT really didn't work with system
catalogs. But, if I'm not mistaken, never in a released version.

* Improve grouping of sessions waiting for commit_delay (Peter Geoghegan)

I think this should be under General Performance. It's definitely a
performance feature.

-- 
Peter Geoghegan


-- 
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] 9.3 Beta1 status report

2013-04-20 Thread Pavan Deolasee
On Sun, Apr 21, 2013 at 11:06 AM, Peter Geoghegan p...@heroku.com wrote:

 On Sat, Apr 20, 2013 at 10:02 PM, Bruce Momjian br...@momjian.us wrote:
  I will be working on polishing them for the next ten days, so any
  feedback, patches, or commits are welcome.  I still need to add lots of
  SGML markup.

 I've noticed a few things:

 * Allow heap-only tuple updates on system tables (Andres Freund)

 Didn't Andres just fix a bug wherein HOT updates usually wouldn't
 occur on system tables following the commit of the foreign key locks
 patch? While HOT's development occurred at a time before I followed
 pgsql-hackers, I seem to recall someone telling me that Tom insisted
 upon HOT working with system catalogs specifically because if it
 wasn't good enough to work there, it wasn't good enough to work
 anywhere, or something like that. I guess the source of the confusion
 is specifically that at one point HOT really didn't work with system
 catalogs. But, if I'm not mistaken, never in a released version.


Yeah, HOT was always supported on the system tables in the released
versions. Early days, I tried to convince Tom that its OK to not support
HOT on system tables because updating it frequently is not that common. But
he rejected that on the grounds you explained above. Similarly, we had
other limitations such as CREATE INDEX CONCURRENTLY was broken in the early
submitted versions, but Tom insisted on getting that to work as well before
he will consider the patch. In retrospect, even though we had to burn
midnight oil to get all those limitations straight up, IMHO it made the
code more solid. Of course, Tom had a magic eye to find many corner cases,
fix them and simplify the code before committing the patch.

Andreas reported and fixed a bug which was an oversight in the FK locks
patch. I think he also discovered an old bug that the tableoid was not
being properly checked for HOT conditions but that had very limited impact
since its not common to have indexes on tableoids.

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee