Re: [HACKERS] Proposal : REINDEX SCHEMA

On Tue, Dec 9, 2014 at 10:10 AM, Michael Paquier wrote: > On Tue, Dec 2, 2014 at 3:42 PM, Michael Paquier > wrote: >> Adding on top of that a couple of things cleaned up, like docs and >> typos, and I got the patch attached. Let's have a committer have a >> look a it now, I am marking that as "Re

Re: [HACKERS] Misunderstanding on the FSM README file

2014-12-07 15:07 GMT+01:00 Heikki Linnakangas : > On 12/07/2014 02:03 PM, Guillaume Lelarge wrote: > >> Hi, >> >> I've been reading the FSM README file lately >> (src/backend/storage/freespace/README), and I'm puzzled by one of the >> graph >> (the binary tree structure of an FSM file). Here it is

Re: [HACKERS] On partitioning

On Tue, Dec 9, 2014 at 12:59 PM, Amit Kapila wrote: > On Tue, Dec 9, 2014 at 8:08 AM, Amit Langote > wrote: >> > From: Robert Haas [mailto:robertmh...@gmail.com] >> > I don't understand. If you want to range partition on columns (a, b), >> > you say that, say, tuples with (a, b) values less tha

Re: [HACKERS] Parallel Seq Scan

On Mon, Dec 8, 2014 at 11:27 PM, Robert Haas wrote: > > On Sat, Dec 6, 2014 at 7:07 AM, Stephen Frost wrote: > > For my 2c, I'd like to see it support exactly what the SeqScan node > > supports and then also what Foreign Scan supports. That would mean we'd > > then be able to push filtering down

Re: [HACKERS] Parallel Seq Scan

On Mon, Dec 8, 2014 at 11:21 PM, Robert Haas wrote: > > On Sat, Dec 6, 2014 at 1:50 AM, Amit Kapila wrote: > > I think we have access to this information in planner (RelOptInfo -> pages), > > if we want, we can use that to eliminate the small relations from > > parallelism, but question is how bi

Re: [HACKERS] moving from contrib to bin

On Mon, Dec 8, 2014 at 9:00 PM, Andres Freund wrote: > I actually think both are quite useful when setting up new systems to > quickly screen for problems. There still is a fairly large number of > virtualized systems with pretty much broken timing functions; and > checking whether fsync actually

Re: [HACKERS] Compression of full-page-writes

On Mon, Dec 8, 2014 at 3:17 PM, Simon Riggs wrote: > > On 8 December 2014 at 11:46, Michael Paquier wrote: > > I don't really like those new names, but I'd prefer > > wal_compression_level if we go down that road with 'none' as default > > value. We may still decide in the future to support compr

Re: [HACKERS] moving from contrib to bin

On 2014-12-08 22:50:30 -0500, Tom Lane wrote: > I'm not exactly convinced that we want to encourage packagers to include > either pg_test_fsync or pg_test_timing in standard packages. They are not > all that useful to ordinary users. I actually think both are quite useful when setting up new syst

Re: [HACKERS] On partitioning

On Tue, Dec 9, 2014 at 1:42 AM, Robert Haas wrote: > On Mon, Dec 8, 2014 at 2:56 PM, Andres Freund wrote: > >> I don't think that's mutually exclusive with the idea of > >> partitions-as-tables. I mean, you can add code to the ALTER TABLE > >> path that says if (i_am_not_the_partitioning_root) e

Re: [HACKERS] On partitioning

On Tue, Dec 9, 2014 at 8:08 AM, Amit Langote wrote: > > From: Robert Haas [mailto:robertmh...@gmail.com] > > On Sat, Dec 6, 2014 at 2:59 AM, Amit Kapila > > wrote: > > >> I guess you could list or hash partition on multiple columns, too. > > > > > > How would you distinguish values in list partit

Re: [HACKERS] moving from contrib to bin

Peter Eisentraut writes: > Last time this was attempted, the discussion got lost in exactly which > extensions are worthy enough to be considered official or something like > that. I want to dodge that here by starting at the opposite end: > 1. move programs to src/bin/ > Here are the contrib pr

[HACKERS] moving from contrib to bin

Let's take another crack at moving stuff out of contrib. Nobody likes contrib. The task is only finding something that most people like better. Last time this was attempted, the discussion got lost in exactly which extensions are worthy enough to be considered official or something like that. I

Re: [HACKERS] On partitioning

> From: Robert Haas [mailto:robertmh...@gmail.com] > On Sat, Dec 6, 2014 at 2:59 AM, Amit Kapila > wrote: > >> I guess you could list or hash partition on multiple columns, too. > > > > How would you distinguish values in list partition for multiple > > columns? I mean for range partition, we are

Re: [HACKERS] alter user set local_preload_libraries.

Peter Eisentraut writes: > On 12/8/14 12:39 PM, Robert Haas wrote: >> On Sun, Dec 7, 2014 at 9:54 AM, Peter Eisentraut wrote: >>> My radical proposal therefore would have been to embrace this >>> inconsistency and get rid of PGC_BACKEND and PGC_SU_BACKEND altogether, >>> relying on users interpre

Re: [HACKERS] Status of Commit fest 2014-10

On 12/08/2014 09:19 AM, Michael Paquier wrote: > - Use faster, higher precision timer API GetSystemTimeAsFileTime on windows This is now committed. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hacke

Re: [HACKERS] alter user set local_preload_libraries.

On 12/8/14 12:39 PM, Robert Haas wrote: > On Sun, Dec 7, 2014 at 9:54 AM, Peter Eisentraut wrote: >> My radical proposal therefore would have been to embrace this >> inconsistency and get rid of PGC_BACKEND and PGC_SU_BACKEND altogether, >> relying on users interpreting the parameter names to indi

Re: [HACKERS] pg_recvlogical description

On Mon, Dec 8, 2014 at 11:53 PM, Euler Taveira wrote: > Hi, > > The pg_recvlogical docs was rewritten but someone forgot to tweak the > help description. It is a bit late in the 9.4 cycle but let be consistent. Yeah, that makes sense. +1 for making docs consistent on master. For 9.4 this is a bit

Re: [HACKERS] Proposal : REINDEX SCHEMA

On Tue, Dec 2, 2014 at 3:42 PM, Michael Paquier wrote: > Adding on top of that a couple of things cleaned up, like docs and > typos, and I got the patch attached. Let's have a committer have a > look a it now, I am marking that as "Ready for Committer". For the archives, this has been committed as

Re: [HACKERS] On partitioning

On 12/08/2014 02:12 PM, Jim Nasby wrote: > On 12/8/14, 12:26 PM, Josh Berkus wrote: >> 4. Creation Locking Problem >> high probability of lock pile-ups whenever a new partition is created on >> demand due to multiple backends trying to create the partition at the >> same time. >> Not Addressed? >

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 9 December 2014 at 06:28, Jim Nasby wrote: > On 12/7/14, 6:16 PM, Simon Riggs wrote: >> What I'm more interested in is what you plan to do with the >> information once we get it? >> >> The assumption that skipping blocks is something bad is strange. I >> added it because VACUUM could and did r

Re: [HACKERS] Compression of full-page-writes

On 9 December 2014 at 04:21, Andres Freund wrote: > On 2014-12-08 14:09:19 -0500, Robert Haas wrote: >> > records, just fpis. There is no evidence that we even want to compress >> > other record types, nor that our compression mechanism is effective at >> > doing so. Simple => keep name as compres

Re: [HACKERS] Compression of full-page-writes

On 9 December 2014 at 04:09, Robert Haas wrote: > On Sun, Dec 7, 2014 at 9:30 PM, Simon Riggs wrote: >> * parameter should be SUSET - it doesn't *need* to be set only at >> server start since all records are independent of each other > > Why not USERSET? There's no point in trying to prohibit us

Re: [HACKERS] On partitioning

On 12/8/14, 12:26 PM, Josh Berkus wrote: 4. Creation Locking Problem high probability of lock pile-ups whenever a new partition is created on demand due to multiple backends trying to create the partition at the same time. Not Addressed? Do users actually try and create new partitions during DM

Re: [HACKERS] On partitioning

On 12/8/14, 1:05 PM, Robert Haas wrote: Besides, I haven't really seen anyone propose something that sounds like a credible alternative. If we could make partition objects things that the storage layer needs to know about but the query planner doesn't need to understand, that'd be maybe worth co

Re: [HACKERS] Role Attribute Bitmask Catalog Representation

On Tue, Dec 9, 2014 at 12:10 AM, Adam Brightwell wrote: > Michael, > >> >> > This work will certainly continue to be pursued. If a simple move is >> > possible/acceptable, then I think that would be the best option. I can >> > handle that as it would appear that I am capable of moving it, if tha

Re: [HACKERS] Compression of full-page-writes

On Tue, Dec 9, 2014 at 5:33 AM, Heikki Linnakangas wrote: > On 12/08/2014 09:21 PM, Andres Freund wrote: >> >> I still think that just compressing the whole record if it's above a >> certain size is going to be better than compressing individual >> parts. Michael argued thta that'd be complicated

Re: [HACKERS] Casting issues with domains

On 12/8/14, 9:18 AM, Tom Lane wrote: The short answer is that SQL domains are not zero-cost type aliases. Perhaps there would be value in having a feature that*is* a a zero-cost alias, but it wouldn't be a domain. Note that you can actually re-use the support functions of one data type to crea

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 12/7/14, 6:16 PM, Simon Riggs wrote: On 20 October 2014 at 10:57, Jim Nasby wrote: Currently, a non-freeze vacuum will punt on any page it can't get a cleanup lock on, with no retry. Presumably this should be a rare occurrence, but I think it's bad that we just assume that and won't warn th

Re: [HACKERS] [v9.5] Custom Plan API

On 12/6/14, 5:21 PM, Kouhei Kaigai wrote: > >Yes please. We have other contrib modules that exist as tests, so this > >seems reasonable to me. > >I can't improve the docs without the example code. Is that available now? > Please wait for a few days. The ctidscan module is not adjusted for the l

Re: [HACKERS] Compression of full-page-writes

On 12/08/2014 09:21 PM, Andres Freund wrote: I still think that just compressing the whole record if it's above a certain size is going to be better than compressing individual parts. Michael argued thta that'd be complicated because of the varying size of the required 'scratch space'. I don't bu

Re: [HACKERS] On partitioning

On Mon, Dec 8, 2014 at 2:58 PM, Josh Berkus wrote: >> I think any new partitioning system should keep the good things about >> the existing system, of which there are some, and not try to reinvent >> the wheel. The yard stick for a new system shouldn't be "is this >> different enough?" but "does

Re: [HACKERS] On partitioning

On Mon, Dec 8, 2014 at 2:56 PM, Andres Freund wrote: >> I don't think that's mutually exclusive with the idea of >> partitions-as-tables. I mean, you can add code to the ALTER TABLE >> path that says if (i_am_not_the_partitioning_root) ereport(ERROR, ...) >> wherever you want. > > That'll be a lo

Re: [HACKERS] On partitioning

On 12/08/2014 11:40 AM, Robert Haas wrote: >> I don't thing its feasible to drop inheritance partitioning at this >> point; too many user exploit a lot of peculiarities of that system which >> wouldn't be supported by any other system. So any new partitioning >> system we're talking about would be

Re: [HACKERS] On partitioning

On 2014-12-08 14:48:50 -0500, Robert Haas wrote: > On Mon, Dec 8, 2014 at 2:39 PM, Andres Freund wrote: > >> I guess I'm in disagreement with you - and, perhaps - the majority on > >> this point. I think that ship has already sailed: partitions ARE > >> tables. We can try to make it less necessa

Re: [HACKERS] Lockless StrategyGetBuffer() clock sweep

On 2014-10-30 07:55:08 -0400, Robert Haas wrote: > On Wed, Oct 29, 2014 at 3:09 PM, Andres Freund wrote: > >> But if it is, then how about > >> adding a flag that is 4 bytes wide or less alongside bgwriterLatch, > >> and just checking the flag instead of checking bgwriterLatch itself? > > > > Yea,

Re: [HACKERS] On partitioning

On Mon, Dec 8, 2014 at 2:39 PM, Andres Freund wrote: >> I guess I'm in disagreement with you - and, perhaps - the majority on >> this point. I think that ship has already sailed: partitions ARE >> tables. We can try to make it less necessary for users to ever look >> at those tables as separate

[HACKERS] compiler warnings under MinGW for 9.4

In the past, building under MinGW produced so many warnings that I never bothered to read them. Now most of them have been removed, so the ones that are left might be worth reporting. Using gcc.exe (GCC) 4.6.2 on REL9_4_STABLE eadd80c08ddfc485db84b9af7cca54a0d50ebe6d I get: mingwcompat.c:60:1: w

Re: [HACKERS] On partitioning

On Mon, Dec 8, 2014 at 2:30 PM, Josh Berkus wrote: > On 12/08/2014 11:05 AM, Robert Haas wrote: >> I guess I'm in disagreement with you - and, perhaps - the majority on >> this point. I think that ship has already sailed: partitions ARE >> tables. We can try to make it less necessary for users t

Re: [HACKERS] On partitioning

On 2014-12-08 14:05:52 -0500, Robert Haas wrote: > On Sat, Dec 6, 2014 at 3:06 AM, Amit Kapila wrote: > > Sure, I don't feel we should not provide anyway to take dump > > for individual partition but not at level of independent table. > > May be something like --table > > --partition . > > > > In

Re: [HACKERS] Compression of full-page-writes

On Mon, Dec 8, 2014 at 2:21 PM, Andres Freund wrote: > On 2014-12-08 14:09:19 -0500, Robert Haas wrote: >> > records, just fpis. There is no evidence that we even want to compress >> > other record types, nor that our compression mechanism is effective at >> > doing so. Simple => keep name as comp

Re: [HACKERS] On partitioning

On 12/08/2014 11:05 AM, Robert Haas wrote: > I guess I'm in disagreement with you - and, perhaps - the majority on > this point. I think that ship has already sailed: partitions ARE > tables. We can try to make it less necessary for users to ever look > at those tables as separate objects, and I

Re: [HACKERS] Compression of full-page-writes

On 2014-12-08 14:09:19 -0500, Robert Haas wrote: > > records, just fpis. There is no evidence that we even want to compress > > other record types, nor that our compression mechanism is effective at > > doing so. Simple => keep name as compress_full_page_writes > > Quite right. I don't really agr

Re: [HACKERS] Compression of full-page-writes

On Sun, Dec 7, 2014 at 9:30 PM, Simon Riggs wrote: > * parameter should be SUSET - it doesn't *need* to be set only at > server start since all records are independent of each other Why not USERSET? There's no point in trying to prohibit users from doing things that will cause bad performance be

Re: [HACKERS] On partitioning

On Sat, Dec 6, 2014 at 3:06 AM, Amit Kapila wrote: > Sure, I don't feel we should not provide anyway to take dump > for individual partition but not at level of independent table. > May be something like --table > --partition . > > In general, I think we should try to avoid exposing that partitio

Re: [HACKERS] On partitioning

On Mon, Dec 8, 2014 at 12:13 AM, Amit Langote wrote: > So just to clarify, first and last destinations are considered "defined" if > you have something like: > > ... > PARTITION p1 VALUES LESS THAN 10 > PARTITION p2 VALUES BETWEEN 10 AND 20 > PARTITION p3 VALUES GREATER THAN 20 > ... > > And "not

Re: [HACKERS] On partitioning

On Sat, Dec 6, 2014 at 2:59 AM, Amit Kapila wrote: >> I guess you could list or hash partition on multiple columns, too. > > How would you distinguish values in list partition for multiple > columns? I mean for range partition, we are sure there will > be either one value for each column, but for

Re: [HACKERS] On partitioning

All, Pardon me for jumping into this late. In general, I like Alvaro's approach. However, I wanted to list the major shortcomings of the existing replication system (based on complaints by PGX's users and on IRC) and compare them to Alvaro's proposed implementation to make sure that enough of th

Re: [HACKERS] jsonb generator functions

On 12/08/2014 04:21 AM, Alvaro Herrera wrote: Andrew Dunstan wrote: OK, here is a new patch version that * uses find_coercion_path() to find the cast function if any, as discussed elsewhere * removes calls to getTypeOutputInfo() except where required * honors a cast to json only for

Re: [HACKERS] Parallel Seq Scan

On Sat, Dec 6, 2014 at 7:07 AM, Stephen Frost wrote: > For my 2c, I'd like to see it support exactly what the SeqScan node > supports and then also what Foreign Scan supports. That would mean we'd > then be able to push filtering down to the workers which would be great. > Even better would be fi

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

On Mon, Dec 8, 2014 at 9:43 AM, Peter Geoghegan wrote: > I think it's very possible that the wrong alias may be provided by the > user, and that we should consider that when providing a hint. Note that the existing mechanism (the mechanism that I'm trying to improve) only ever shows this error me

Re: [HACKERS] Parallel Seq Scan

On Sat, Dec 6, 2014 at 1:50 AM, Amit Kapila wrote: > I think we have access to this information in planner (RelOptInfo -> pages), > if we want, we can use that to eliminate the small relations from > parallelism, but question is how big relations do we want to consider > for parallelism, one way i

Re: [HACKERS] Parallel Seq Scan

On Sat, Dec 6, 2014 at 12:13 AM, David Rowley wrote: > It's bare-bones core support for allowing aggregate states to be merged > together with another aggregate state. I would imagine that if a query such > as: > > SELECT MAX(value) FROM bigtable; > > was run, then a series of parallel workers cou

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

On Mon, Dec 8, 2014 at 9:31 AM, Robert Haas wrote: > Just that that's the case in which it seems useful to give a hint. I think it's very possible that the wrong alias may be provided by the user, and that we should consider that when providing a hint. Besides, considering every visible RTE (whil

Re: [HACKERS] Testing DDL deparsing support

On Sat, Dec 6, 2014 at 10:43 PM, Bruce Momjian wrote: > This causes creation DDL is checked if it is used in the regression > database, but what about ALTER and DROP? pg_dump doesn't issue those, > except in special cases like inheritance. The proposed testing mechanism should cover any ALTER co

Re: [HACKERS] alter user set local_preload_libraries.

On Sun, Dec 7, 2014 at 9:54 AM, Peter Eisentraut wrote: > My radical proposal therefore would have been to embrace this > inconsistency and get rid of PGC_BACKEND and PGC_SU_BACKEND altogether, > relying on users interpreting the parameter names to indicate that > changing them later may or may no

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

On Fri, Dec 5, 2014 at 3:45 PM, Peter Geoghegan wrote: > On Fri, Dec 5, 2014 at 12:33 PM, Robert Haas wrote: >>> Well, if an alias is used, and you refer to an attribute using a >>> non-alias name (i.e. the original table name), then you'll already get >>> an error suggesting that the alias be us

[HACKERS] Dumping database creation options and ACLs

Hello. As of now, the only way to restore database options and ACLs is to use pg_dumpall without the globals options. The often recommended pg_dumpall -g + individual dumps of the target databases doesn't restore those. Since pg_dump/pg_restore offer the ability to create the database, it shoul

Re: [HACKERS] Casting issues with domains

Thomas Reiss writes: > postgres=# explain select * from test2 where a='toto'; > QUERY PLAN > -- > Seq Scan on test1 (cost=0.00..1693.00 rows=500 width=5) >Filter: (((a)::tstdom)::text = 'toto'::text) > (2 lignes)

Re: [HACKERS] Role Attribute Bitmask Catalog Representation

Michael, > > This work will certainly continue to be pursued. If a simple move is > > possible/acceptable, then I think that would be the best option. I can > > handle that as it would appear that I am capable of moving it, if that is > > acceptable. > Yes please. Actually I could have done it,

[HACKERS] pg_recvlogical description

Hi, The pg_recvlogical docs was rewritten but someone forgot to tweak the help description. It is a bit late in the 9.4 cycle but let be consistent. Regards, -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e

Re: [HACKERS] advance local xmin more aggressively

On Mon, Dec 8, 2014 at 4:56 AM, Heikki Linnakangas wrote: > I don't immediately see the problem either, but I have to say that > grovelling through all the resource owners seems ugly anyway. Resource > owners are not meant to be traversed like that. And there could be a lot of > them, and you have

Re: [HACKERS] inherit support for foreign tables

(2014/12/08 15:17), Ashutosh Bapat wrote: On Sat, Dec 6, 2014 at 9:21 PM, Noah Misch mailto:n...@leadboat.com>> wrote: Does this inheritance patch add any atomicity problem that goes away when one breaks up the inheritance hierarchy and UPDATEs each table separately? If not, this

Re: [HACKERS] [Windows,PATCH] Use faster, higher precision timer API

On 12/05/2014 08:03 PM, David Rowley wrote: > On 2 December 2014 at 15:36, Craig Ringer > wrote: > > On 12/01/2014 09:51 PM, Marco Nenciarini wrote: > > I think this is a leftover, as you don't use elog afterwards. > > Good catch, fixed. > > I've looked

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Fri, 2014-12-05 at 10:00 -0800, Josh Berkus wrote: > I thought the point of INSERT ... ON CONFLICT update was so that you > didn't have to care if it was a new row or not? > > If you do care, it seems like it makes more sense to do your own INSERTs > and UPDATEs, as Django currently does. Djan

[HACKERS] Casting issues with domains

Hello all, We experienced some casting issues with domains. We experienced the problem while querying the information_schema btw, but here is a simpler test case : postgres=# create table test1 (a text); CREATE TABLE postgres=# insert into test1 select generate_series(1,10); INSERT 0 10

Re: [HACKERS] advance local xmin more aggressively

On 12/05/2014 05:05 PM, Robert Haas wrote: [ reviving a very old thread ] On Tue, Feb 10, 2009 at 4:11 PM, Tom Lane wrote: Alvaro Herrera writes: For example, maybe we could keep track of counts of snapshots removed since the last xmin calculation, and only run this routine if the number is

Re: [HACKERS] Compression of full-page-writes

On 8 December 2014 at 11:46, Michael Paquier wrote: >> * ideally we'd like to be able to differentiate the types of usage. >> which then allows the user to control the level of compression >> depending upon the type of action. My first cut at what those settings >> should be are ALL > LOGICAL > P

Re: [HACKERS] jsonb generator functions

Andrew Dunstan wrote: > OK, here is a new patch version that > > * uses find_coercion_path() to find the cast function if any, as >discussed elsewhere > * removes calls to getTypeOutputInfo() except where required > * honors a cast to json only for rendering both json and jsonb > * adds p