Re: [HACKERS] i feel like compelled !

On 14/05/15 09:35, essam Gndelee essam wrote: hi i don't want to make this post long. i just started to use PostgreSQL and it is absolutely awesome . just want to say thank you very much You're allowed to say more!!! :-) What particular features do you like best, and why? What O/S, hardware

Re: [HACKERS] Additional role attributes && superuser review

On 30/04/15 12:20, Alvaro Herrera wrote: Robert Haas wrote: I think that if you commit this the way you have it today, everybody will go, oh, look, Stephen committed something, but it looks complicated, I won't pay attention. Yeah, that sucks. Finally, you've got the idea of making pg_ a res

Re: [HACKERS] Rounding to even for numeric data type

On 29/03/15 13:07, David G. Johnston wrote: On Sat, Mar 28, 2015 at 3:59 PM, Michael Paquier mailto:michael.paqu...@gmail.com>>wrote: On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower mailto:gavinflo...@archidevsys.co.nz>> wrote: > On 28/03/15 21:58, Dea

Re: [HACKERS] Rounding to even for numeric data type

On 28/03/15 21:58, Dean Rasheed wrote: [...] Andrew mentioned that there have been complaints from people doing calculations with monetary data that we don't implement round-to-nearest-even (Banker's) rounding. It's actually the case that various different financial calculations demand different

Re: [HACKERS] INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0

On 27/03/15 09:14, Peter Geoghegan wrote: On Thu, Mar 26, 2015 at 2:51 PM, Heikki Linnakangas wrote: [...] Oops - You're right. I find it interesting that this didn't result in breaking my test cases. [...] Reminds of the situation where I got an A++ for a COBOL programming assignment that

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On 22/03/15 08:48, Joshua D. Drake wrote: On 03/21/2015 12:45 PM, Gavin Flower wrote: How about 2 config files? One marked adult^H^H^H^H^H power users only, or some such, with the really dangerous or unusual options? That has come up before in many threads. I don't know that we ne

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On 22/03/15 08:34, Joshua D. Drake wrote: On 03/21/2015 12:00 AM, Mark Kirkwood wrote: -1 Personally I'm against hiding *any* settings. Choosing sensible defaults - yes! Hiding them - that reeks of secret squirrel nonsense and overpaid Oracle dbas that knew the undocumented settings for vari

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On 22/03/15 05:42, David G. Johnston wrote: On Sat, Mar 21, 2015 at 8:54 AM, Tom Lane >wrote: Stephen Frost mailto:sfr...@snowman.net>> writes: > At the moment, one could look at our default postgresql.conf and the > "turns forced synchronization on or off"

Re: [HACKERS] Order of enforcement of CHECK constraints?

On 21/03/15 08:15, Tom Lane wrote: My Salesforce colleagues noticed some tests flapping as a result of table CHECK constraints not always being enforced in the same order; ie, if a tuple insertion/update violates more than one CHECK constraint, it's not deterministic which one is reported. This

Re: [HACKERS] Allow "snapshot too old" error, to prevent bloat

On 16/03/15 13:04, Rui DeSousa wrote: Would a parameter to auto terminate long running transactions be a better solution? Terminating the long running transaction would allow for the normal vacuuming process to cleanup the deleted records thus avoiding database bloat without introducing new se

Re: [HACKERS] Patch: raise default for max_wal_segments to 1GB

On 04/03/15 08:57, Tom Lane wrote: Josh Berkus writes: Do we want to remove unit comments from all settings which accept "MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of this, but seems like (a) it should be universal, and (b) its own patch. Meh. Doing this strikes me as a

Re: [HACKERS] logical column ordering

On 28/02/15 18:34, Jim Nasby wrote: On 2/27/15 2:49 PM, Alvaro Herrera wrote: Tomas Vondra wrote: 1) change the order of columns in "SELECT *" - display columns so that related ones grouped together (irrespectedly whether they were added later, etc.) FWIW, I find the ordering more

Re: [HACKERS] logical column ordering

On 28/02/15 12:21, Josh Berkus wrote: On 02/27/2015 03:06 PM, Tomas Vondra wrote: On 27.2.2015 23:48, Josh Berkus wrote: Actually, I'm going to go back on what I said. We need an API for physical column reordering, even if it's just pg_ functions. The reason is that we want to enable people w

Re: [HACKERS] logical column ordering

On 28/02/15 09:49, Alvaro Herrera wrote: Tomas Vondra wrote: 1) change the order of columns in "SELECT *" - display columns so that related ones grouped together (irrespectedly whether they were added later, etc.) - keep columns synced with COPY - requires user interface (A

Re: [HACKERS] logical column ordering

On 28/02/15 09:09, Josh Berkus wrote: Tomas, So for an API, 100% of the use cases I have for this feature would be satisfied by: ALTER TABLE __ ALTER COLUMN _ SET ORDER # and: ALTER TABLE _ ADD COLUMN colname coltype ORDER # If that's infeasible, a function would be less optimal,

Re: [HACKERS] logical column ordering

On 27/02/15 14:08, David Steele wrote: [...] I agree with Jim's comments. I've generally followed column ordering that goes something like: 1) primary key 2) foreign keys 3) flags 4) other programmatic data fields (type, order, etc.) 5) non-programmatic data fields (name, description, etc.) Th

Re: [HACKERS] PostgreSQL on z/OS UNIX?

On 25/02/15 11:12, Tom Lane wrote: Gord Tomlin writes: z/OS UNIX does have certification as a UNIX system, but there are some quirks. The most common sources of problems when porting packages to z/OS UNIX are its use of EBCDIC, and autoconf problems. I guess it's time for some fail/rinse/repeat

Re: [HACKERS] Abbreviated keys for Numeric

On 22/02/15 22:59, Andrew Gierth wrote: "Gavin" == Gavin Flower writes: Gavin> What are the standard deviations? Gavin> Do the arithmetic means change much if you exclude the 2 fastest Gavin> & 2 slowest? Gavin> How do the arithmetic means compare t

Re: [HACKERS] Abbreviated keys for Numeric

On 21/02/15 18:18, Tomas Vondra wrote: Hi, On 21.2.2015 02:06, Tomas Vondra wrote: On 21.2.2015 02:00, Andrew Gierth wrote: "Tomas" == Tomas Vondra writes: >> Right...so don't test a datum sort case, since that isn't supported >> at all in the master branch. Your test case is invalid for

Re: [HACKERS] Expanding the use of FLEXIBLE_ARRAY_MEMBER for declarations like foo[1]

On 19/02/15 15:00, Tom Lane wrote: Michael Paquier writes: On Thu, Feb 19, 2015 at 7:29 AM, Tom Lane wrote: Moreover, if we have any code that is assuming such cases are okay, it probably needs a second look. Isn't this situation effectively assuming that a variable-length array is fixed-len

Re: [HACKERS] Re: Abbreviated keys for Numeric

On 28/01/15 06:29, Andrew Gierth wrote: "Peter" == Peter Geoghegan writes: Peter> What I find particularly interesting about this patch is that it Peter> makes sorting numerics significantly faster than even sorting Peter> float8 values, Played some more with this. Testing on some differ

Re: [HACKERS] Parallel Seq Scan

On 20/12/14 03:54, Heikki Linnakangas wrote: On 12/19/2014 04:39 PM, Stephen Frost wrote: * Marko Tiikkaja (ma...@joh.to) wrote: On 12/19/14 3:27 PM, Stephen Frost wrote: We'd have to coach our users to constantly be tweaking the enable_parallel_query (or whatever) option for the queries where

Re: [HACKERS] Commitfest problems

On 19/12/14 07:02, Joshua D. Drake wrote: On 12/18/2014 04:53 AM, Torsten Zuehlsdorff wrote: Having your name in a list of other names at the bottom of the release notes page, without any indication of what you helped with, would work better? Perhaps it would but I tend to doubt it. Out of

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

On 17/12/14 10:11, Peter Geoghegan wrote: On Tue, Dec 16, 2014 at 11:08 AM, Jeff Janes wrote: Your new version 1.7 of the patches fixes that issue, as well as the OID conflict. Good. You're probably aware that I maintain a stress testing suite for the patch here: https://github.com/petergeogh

Re: [HACKERS] two dimensional statistics in Postgres

On 06/11/14 23:57, Tomas Vondra wrote: Dne 6 Listopad 2014, 11:50, Gavin Flower napsal(a): Could you store a 2 dimensional histogram in a one dimensional array: A[z] = value, where z = col * rowSize + row (zero starting index)? How would that work for columns with different data types? Tomas

Re: [HACKERS] two dimensional statistics in Postgres

On 06/11/14 23:15, Katharina Büchse wrote: Hi, I'm a phd-student at the university of Jena, Thüringen, Germany, in the field of data bases, more accurate query optimization. I want to implement a system in PostgreSQL that detects column correlations and creates statistical data about correlate

Re: [HACKERS] Column Redaction

On 10/10/14 21:57, Simon Riggs wrote: Postgres currently supports column level SELECT privileges. 1. If we want to confirm a credit card number, we can issue SELECT 1 FROM customer WHERE stored_card_number = '1234 5678 5344 7733' 2. If we want to look for card fraud, we need to be able to use t

Re: [HACKERS] UPSERT wiki page, and SQL MERGE syntax

On 10/10/14 12:38, Jim Nasby wrote: On 10/8/14, 5:51 PM, Peter Geoghegan wrote: On Wed, Oct 8, 2014 at 2:01 PM, Kevin Grittner wrote: >Although the last go-around does suggest that there is at least one >point of difference on the semantics. You seem to want to fire the >BEFORE INSERT trigger

Re: [HACKERS] What exactly is our CRC algorithm?

On 09/10/14 10:13, Andres Freund wrote: On 2014-10-08 22:13:46 +0300, Heikki Linnakangas wrote: Hmm. So the simple, non-table driven, calculation gives the same result as using the lookup table using the reflected lookup code. That's expected; the lookup method is supposed to be the same, just f

Re: [HACKERS] Proposal for better support of time-varying timezone abbreviations

On 06/10/14 10:33, Tom Lane wrote: I got interested in the problem discussed in http://www.postgresql.org/message-id/20714.1412456...@sss.pgh.pa.us to wit: It's becoming clear to me that our existing design whereby zone abbreviations represent fixed GMT offsets isn't really good enough. I've be

Re: [HACKERS] Time measurement format - more human readable

Please don't top post, initial context is important, especially Tom's! :-) (see my reply below) On 01/10/14 03:52, Bogdan Pilch wrote: How about, the format of psql duration can be set via some ... backslash command or commdn line switch? And the default of course remains the current behavior?

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

On 29/09/14 14:20, Peter Geoghegan wrote: On Sun, Sep 28, 2014 at 6:15 PM, Gavin Flower wrote: What I have a problem with is using the MERGE syntax to match people's preexisting confused ideas about what MERGE does. If we do that, it'll definitely bite us when we go to make wh

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

On 29/09/14 11:57, Peter Geoghegan wrote: On Sun, Sep 28, 2014 at 3:41 PM, Gavin Flower wrote: How about have a stub page for MERGE, saying it is not implemented yet, but how about considering UPSERT - or something of that nature? I can suspect that people are much more likely to look for

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

On 29/09/14 09:31, Peter Geoghegan wrote: On Sun, Sep 28, 2014 at 1:17 PM, Simon Riggs wrote: MERGE INTO tab USING VALUES ('foo') WHEN NOT MATCHED THEN INSERT (colB) WHEN MATCHED THEN UPDATE SET colB = NEW.p1 and throwing "ERROR: full syntax for MERGE not implemented yet" if people stretch

Re: [HACKERS] Time measurement format - more human readable

On 29/09/14 00:49, Bogdan Pilch wrote: Hi, I have created a small patch to postgres source (in particular the psql part of it) that modifies the way time spent executing the SQL commands is printed out. The idea is to have a human readable time printed, e.g.: Time: 1:32:15.45 m:s:ms Time: 2_10:1

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

On 27/09/14 11:36, Gregory Smith wrote: On 9/26/14, 2:38 PM, Gavin Flower wrote: Curious: would it be both feasible and useful to have multiple workers process a 'large' table, without complicating things too much? The could each start at a different position in the file.

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

On 27/09/14 01:36, Alvaro Herrera wrote: Amit Kapila wrote: Today while again thinking about the startegy used in patch to parallelize the operation (vacuum database), I think we can improve the same for cases when number of connections are lesser than number of tables in database (which I pres

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

On 26/09/14 08:21, Simon Riggs wrote: On 25 September 2014 20:11, Robert Haas wrote: My approach would be to insert an index tuple for that value into the index, but with the leaf ituple marked with an xid rather than a ctid. If someone tries to insert into the index they would see this and wa

Re: [HACKERS] Postgres code for a query intermediate dataset

On 14/09/14 06:35, Atri Sharma wrote: On Sat, Sep 13, 2014 at 11:52 PM, David G Johnston mailto:david.g.johns...@gmail.com>> wrote: Atri Sharma wrote > On Sat, Sep 13, 2014 at 11:06 PM, Rohit Goyal < Or rather even if you want to be able to reference the older versions of

Re: [HACKERS] Aussie timezone database changes incoming

On 12/09/14 01:57, Robert Haas wrote: On Thu, Sep 11, 2014 at 12:20 AM, Craig Ringer wrote: I shouldn't be surprised that Australia gets to change. While the cynic in me thinks this is the usual USA-is-the-center-of-the-universe-ism, in reality it makes sense given relative population and likel

Re: [HACKERS] Display of timestamp in pg_dump custom format

On 04/09/14 08:13, Bruce Momjian wrote: On Thu, May 1, 2014 at 12:09:34PM -0400, Bruce Momjian wrote: On Thu, May 1, 2014 at 12:33:51PM +1200, Gavin Flower wrote: On 01/05/14 12:04, Bruce Momjian wrote: On Thu, May 1, 2014 at 08:27:49AM +1200, Gavin Flower wrote: On 01/05/14 02:51, Bruce

Re: [HACKERS] Built-in binning functions

On 01/09/14 06:00, Tom Lane wrote: Simon Riggs writes: Suggest discretize() as a much more informative name. The other names will be overlooked by anybody that doesn't already know what to look for. I did not like that idea to begin with, but it's growing more attractive. In particular, I thin

Re: [HACKERS] jsonb format is pessimal for toast compression

On 15/08/14 09:47, Tom Lane wrote: Peter Geoghegan writes: On Thu, Aug 14, 2014 at 10:57 AM, Tom Lane wrote: Maybe this is telling us it's not worth changing the representation, and we should just go do something about the first_success_by threshold and be done. I'm hesitant to draw such con

Re: [HACKERS] Proposed changing the definition of decade for date_trunc and extract

On 04/08/14 01:27, Bruce Momjian wrote: On Sat, Aug 2, 2014 at 11:53:06PM -0700, Mike Swanson wrote: On Fri, 2014-08-01 at 22:28 -0700, Mike Swanson wrote: I'd also argue that the current function basing the logic from definition #2 has limited use even when you want to use it for such. If you

Re: [HACKERS] Re: Proposed changing the definition of decade for date_trunc and extract

On 02/08/14 12:32, David G Johnston wrote: Mike Swanson wrote For a long time (since version 8.0), PostgreSQL has adopted the logical barriers for centuries and millenniums in these functions. The calendar starts millennium and century 1 on year 1, directly after 1 BC. Unfortunately decades are

Re: [HACKERS] Proposal for updating src/timezone

On 20/07/14 06:30, John Cochran wrote: On Sat, Jul 19, 2014 at 11:58 AM, Michael Banck > wrote: SNIP Maybe if you pgindent the IANA code as well, you can more easily diff the actual changes between the two, did you try that? Michael Unfortunately, pgind

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

On 18/07/14 04:08, Tom Lane wrote: Christoph Berg writes: One place that's been bugging me where case-insensitivity would really make sense is this: # set work_mem = '1mb'; ERROR: 22023: invalid value for parameter "work_mem": "1mb" HINT: Valid units for this parameter are "kB", "MB", and "GB

Re: [HACKERS] gaussian distribution pgbench

On 03/07/14 20:58, Fabien COELHO wrote: Hello Gavin, decile percents: 69.9% 21.0% 6.3% 1.9% 0.6% 0.2% 0.1% 0.0% 0.0% 0.0% probability of fist/last percent of the range: 11.3% 0.0% I would suggest that probabilities should NEVER be expressed in percentages! As a percentage probability look

Re: [HACKERS] gaussian distribution pgbench

On 02/07/14 21:05, Fabien COELHO wrote: Hello Mitsumasa-san, And I'm also interested in your "decile percents" output like under followings, decile percents: 39.6% 24.0% 14.6% 8.8% 5.4% 3.3% 2.0% 1.2% 0.7% 0.4% Sure, I'm really fine with that. I think that it is easier than before. Sum of d

Re: [HACKERS] buildfarm and "rolling release" distros

On 02/07/14 06:02, Robert Haas wrote: On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan wrote: I've always been a bit reluctant to accept buildfarm members that are constantly being updated, because it seemed to me that it created something with too many variables. However, we occasionally get re

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 27/06/14 00:12, Rushabh Lathia wrote: Thanks for sharing latest patch. For me this syntax is limiting the current returning clause implementation. Because its not allowing the returning PRIMARY KEYS with other columns, and if user or application require that they need to do RETURNING *. Fo

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

On 18/06/14 10:05, Peter Geoghegan wrote: On Tue, Jun 17, 2014 at 2:53 PM, Tom Lane wrote: I'm not proposing an immutable cutoff. Something that scales with the string length might be a good idea, or we could make it a multiple of the minimum observed distance, or probably there are a dozen ot

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 09/06/14 23:42, Vik Fearing wrote: On 06/09/2014 09:06 AM, Gavin Flower wrote: From memory all unique keys can be considered 'candidate primary keys', but only one can be designated 'the PRIMARY KEY'. Almost. Candidate keys are also NOT NULL. Yeah, obviously! (Ex

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 09/06/14 17:47, David G Johnston wrote: Ian Barwick wrote Hi, The JDBC API provides the getGeneratedKeys() method as a way of retrieving primary key values without the need to explicitly specify the primary key column(s). This is a widely-used feature, however the implementation has signific

Re: [HACKERS] PG Manual: Clarifying the repeatable read isolation example

On 08/06/14 05:03, Kevin Grittner wrote: [...] I found it hard to decide how far to go in the docs versus the Wiki page. Any suggestions or suggested patches welcome. [...] I know this is subjective, but that seems to me a little too much in an academic style for the docs. In the Wiki page ex

Re: [HACKERS] buildfarm animals and 'snapshot too old'

On 21/05/14 01:42, Tom Lane wrote: Andrew Dunstan writes: On 05/20/2014 07:09 AM, Tom Lane wrote: Robert's got a point here. In my usage, the annoying thing is not animals that take a long time to report in; it's the ones that lie about the snapshot time (which is how you get "512abc4 in the

Re: [HACKERS] New timezones used in regression tests

On 13/05/14 11:16, Tom Lane wrote: Christoph Berg writes: 84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp constructors. In the regression tests, various time zones are tested, including America/Metlakatla. Now, if you configure using --with-system-tzdata, you'll get an error if th

Re: [HACKERS] default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)

On 09/05/14 15:34, Bruce Momjian wrote: On Thu, May 8, 2014 at 06:39:11PM -0400, Tom Lane wrote: I wrote: I think the idea of hashing only keys/values that are "too long" is a reasonable compromise. I've not finished coding it (because I keep getting distracted by other problems in the code :

Re: [HACKERS] Display of timestamp in pg_dump custom format

On 01/05/14 12:04, Bruce Momjian wrote: On Thu, May 1, 2014 at 08:27:49AM +1200, Gavin Flower wrote: On 01/05/14 02:51, Bruce Momjian wrote: The table of contents for pg_restore -l shows the time the archive was made as local time (it uses ctime()): ; Archive created at Wed Apr 30 10

Re: [HACKERS] Display of timestamp in pg_dump custom format

On 01/05/14 02:51, Bruce Momjian wrote: The table of contents for pg_restore -l shows the time the archive was made as local time (it uses ctime()): ; Archive created at Wed Apr 30 10:03:28 2014 Is this clear enough that it is local time? Should we display this better, perhaps with a t

Re: [HACKERS] jsonb and nested hstore

On 15/03/14 08:45, Oleg Bartunov wrote: 9.5 may too optimistic :) On Fri, Mar 14, 2014 at 11:18 PM, Josh Berkus wrote: On 03/14/2014 04:52 AM, Oleg Bartunov wrote: VODKA index will have no lenght limitation. Yeah, so I think we go with what we have, and tell people "if you're hitting these l

Re: [HACKERS] jsonb and nested hstore

On 04/03/14 04:25, Oleg Bartunov wrote: On Mon, Mar 3, 2014 at 7:22 PM, Andres Freund wrote: [...] PS: Not a native speaker either... That's explain all :) [...] I AM a native English speaker born in England - though if you read some of my postings where I've been particularly careless, y

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

On 18/02/14 03:48, Tom Lane wrote: Gavin Flower writes: On 17/02/14 15:26, Robert Haas wrote: I don't really know about cpu_tuple_cost. Kevin's often advocated raising it, but I haven't heard anyone else advocate for that. I think we need data points from more people to know

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

On 17/02/14 15:26, Robert Haas wrote: On Thu, Feb 13, 2014 at 3:34 PM, Bruce Momjian wrote: On Fri, Oct 11, 2013 at 03:39:51PM -0700, Kevin Grittner wrote: Josh Berkus wrote: On 10/11/2013 01:11 PM, Bruce Momjian wrote: In summary, I think we need to: * decide on new defaults for work_mem

Re: [HACKERS] Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)

On 08/02/14 19:05, Tom Lane wrote: Peter Eisentraut writes: On 2/3/14, 8:48 PM, Tom Lane wrote: That's a very fair question. It's a reasonable bet that pretty much nobody actually looks at the text versions of either HISTORY or regress_README anymore. It's conceivable that somebody somewhere

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On 06/02/14 16:59, Robert Haas wrote: On Wed, Feb 5, 2014 at 6:43 AM, Heikki Linnakangas wrote: So, I came up with the attached worst case test, modified from your latest test suite. unpatched: testname | wal_generated | duration

Re: [HACKERS] [COMMITTERS] pgsql: Include planning time in EXPLAIN ANALYZE output.

On 03/02/14 09:44, Peter Geoghegan wrote: On Sun, Feb 2, 2014 at 8:13 AM, Tom Lane wrote: Perhaps s/Total runtime/Execution time/ ? +1 If the planning was ever made into a parallel process, then 'elapsed time' would be less than the 'processor time'. So what does 'Execution time' mean?

Re: [HACKERS] Fix comment typo in /src/backend/command/cluster.c

On 28/01/14 16:33, Andrew Dunstan wrote: On 01/27/2014 10:24 PM, Sawada Masahiko wrote: Hi all, Attached patch fixes the typo which is in "src/backend/command/cluster.c". Are you sure that's a typo? "iff" is usually short hand for "if and only if". cheers andrew Certainly, that is

Re: [HACKERS] [Lsf-pc] Linux kernel impact on PostgreSQL performance

On 14/01/14 14:09, Dave Chinner wrote: On Mon, Jan 13, 2014 at 09:29:02PM +, Greg Stark wrote: On Mon, Jan 13, 2014 at 9:12 PM, Andres Freund wrote: [...] The more ambitious and interesting direction is to let Postgres tell the kernel what it needs to know to manage everything. To do that

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On 14/01/14 14:29, Tom Lane wrote: [...] (2) the float and numeric variants should be implemented under nondefault names (I'm thinking FAST_SUM(), but bikeshed away). People who need extra speed and don't mind the slightly different results can alter their queries to use these variants. One rea

Re: [HACKERS] plpgsql.consistent_into

On 13/01/14 11:44, Florian Pflug wrote: On Jan12, 2014, at 22:37 , Pavel Stehule wrote: There is GUC for variable_conflict already too. In this case I would to enable this functionality everywhere (it is tool how to simply eliminate some kind of strange bugs) so it needs a GUC. We have GUC fo

Re: [HACKERS] Disallow arrays with non-standard lower bounds

On 10/01/14 12:55, Peter Geoghegan wrote: On Thu, Jan 9, 2014 at 3:41 PM, David Fetter wrote: We have dropped support, as you put it, for bigger and harder-hitting mistakes than this. Anybody whose code has this kind of silliness in it will be in other kinds of trouble, too. While the decisio

Re: [HACKERS] Disallow arrays with non-standard lower bounds

On 10/01/14 12:41, David Fetter wrote: [..] David (who is among that tiny minority who believe that arrays should be indexed from 0.5 as a compromise ;) Clearly we should use 1/e as the starting index, where 'e' is Euler's constant 2.718... :-) (Much more mathematically profound!) Cheers, G

Re: [HACKERS] make_interval ??

On 21/12/13 13:40, Josh Berkus wrote: On 12/20/2013 03:09 PM, Gavin Flower wrote: What about leap years? What about them? some years have 365 days others have 366, so how any days in an interval of 2 years?, 4 years? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] make_interval ??

On 21/12/13 06:29, Josh Berkus wrote: Pavel, So constructor should to look like: CREATE OR REPLACE FUNCTION make_interval(years int DEFAULT 0, months int DEFAULT 0, ...) and usage: SELECT make_interval(years := 2) SELECT make_interval(days := 14) Is there a interest for this (or similar) fu

Re: [HACKERS] gaussian distribution pgbench

On 20/12/13 09:36, Peter Geoghegan wrote: On Thu, Nov 21, 2013 at 9:13 AM, Heikki Linnakangas wrote: So what I'd actually like to see is \setgaussian, for use in custom scripts. +1. I'd really like to be able to run a benchmark with a Gaussian and uniform distribution side-by-side for comparat

Re: [HACKERS] [PATCH] SQL assertions prototype

On 18/12/13 10:48, Andrew Dunstan wrote: On 12/17/2013 04:42 PM, Kevin Grittner wrote: Josh Berkus wrote: On 11/15/2013 05:41 AM, Heikki Linnakangas wrote: A fundamental problem with this is that it needs to handle isolation reliable, so that the assertion cannot be violated when two concurr

Re: [HACKERS] SSL: better default ciphersuite

On 18/12/13 05:26, Bruce Momjian wrote: On Tue, Dec 17, 2013 at 09:51:30AM -0500, Robert Haas wrote: On Sun, Dec 15, 2013 at 5:10 PM, James Cloos wrote: For reference, see: https://wiki.mozilla.org/Security/Server_Side_TLS for the currently suggested suite for TLS servers. ... But for p

Re: [HACKERS] ANALYZE sampling is too good

On 12/12/13 09:12, Gavin Flower wrote: On 12/12/13 08:39, Gavin Flower wrote: On 12/12/13 08:31, Kevin Grittner wrote: Gavin Flower wrote: For example, assume 1000 rows of 200 bytes and 1000 rows of 20 bytes, using 400 byte pages. In the pathologically worst case, assuming maximum packing

Re: [HACKERS] ANALYZE sampling is too good

On 12/12/13 08:39, Gavin Flower wrote: On 12/12/13 08:31, Kevin Grittner wrote: Gavin Flower wrote: For example, assume 1000 rows of 200 bytes and 1000 rows of 20 bytes, using 400 byte pages. In the pathologically worst case, assuming maximum packing density and no page has both types: the

Re: [HACKERS] ANALYZE sampling is too good

On 12/12/13 08:31, Kevin Grittner wrote: Gavin Flower wrote: For example, assume 1000 rows of 200 bytes and 1000 rows of 20 bytes, using 400 byte pages. In the pathologically worst case, assuming maximum packing density and no page has both types: the large rows would occupy 500 pages and

Re: [HACKERS] ANALYZE sampling is too good

On 12/12/13 08:14, Gavin Flower wrote: On 12/12/13 07:22, Gavin Flower wrote: On 12/12/13 06:22, Tom Lane wrote: I wrote: Hm. You can only take N rows from a block if there actually are at least N rows in the block. So the sampling rule I suppose you are using is "select up to N rows

Re: [HACKERS] ANALYZE sampling is too good

On 12/12/13 07:22, Gavin Flower wrote: On 12/12/13 06:22, Tom Lane wrote: I wrote: Hm. You can only take N rows from a block if there actually are at least N rows in the block. So the sampling rule I suppose you are using is "select up to N rows from each sampled block" --- a

Re: [HACKERS] ANALYZE sampling is too good

On 12/12/13 06:22, Tom Lane wrote: I wrote: Hm. You can only take N rows from a block if there actually are at least N rows in the block. So the sampling rule I suppose you are using is "select up to N rows from each sampled block" --- and that is going to favor the contents of blocks containi

Re: [HACKERS] ANALYZE sampling is too good

On 12/12/13 06:22, Tom Lane wrote: I wrote: Hm. You can only take N rows from a block if there actually are at least N rows in the block. So the sampling rule I suppose you are using is "select up to N rows from each sampled block" --- and that is going to favor the contents of blocks containi

Re: [HACKERS] ANALYZE sampling is too good

On 08/12/13 10:27, Greg Stark wrote: On Sat, Dec 7, 2013 at 8:25 PM, Josh Berkus wrote: The only approach which makes sense is to base it on a % of the table. In fact, pretty much every paper which has examined statistics estimation for database tables has determined that any estimate based on

Re: [HACKERS] New option for pg_basebackup, to specify a different directory for pg_xlog

On 20/11/13 23:43, Haribabu kommi wrote: On 19 November 2013 19:12 Fujii Masao wrote: On Tue, Nov 19, 2013 at 9:14 PM, Haribabu kommi wrote: On 18 November 2013 23:30 Fujii Masao wrote: On Tue, Nov 19, 2013 at 12:01 AM, Haribabu kommi wrote: Thanks for newer version of the patch! I found t

Re: [HACKERS] additional json functionality

On 20/11/13 05:14, Robert Haas wrote: On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing wrote: I am sure you could also devise an json encoding scheme where white space is significant ;) I don't even have to think hard. If you want your JSON to be human-readable, it's entirely possible that you

Re: [HACKERS] additional json functionality

On 18/11/13 14:51, David E. Wheeler wrote: On Nov 17, 2013, at 5:49 PM, Josh Berkus wrote: Jstore isn't the worst name suggestion I've heard on this thread. The reason I prefer JSONB though, is that a new user looking for a place to put JSON data will clearly realize that JSON and JSONB are a

Re: [HACKERS] additional json functionality

On 18/11/13 09:45, David Johnston wrote: David E. Wheeler-3 wrote I like JSONB because: 1. The "B" means "binary" 2. The "B" means "second" 3. It's short 4. See also BYTEA. "json_strict" : Not sure about the "bytea" reference off-hand... I was pondering "jsons" which meets the short property

Re: [HACKERS] additional json functionality

On 18/11/13 09:02, David E. Wheeler wrote: On Nov 16, 2013, at 2:04 PM, Hannu Krosing wrote: It’s still input and output as JSON, though. Yes, because JavaScript Object Notation *is* a serialization format (aka Notation) for converting JavaScript Objects to text format and back :) I still li

Re: [HACKERS] additional json functionality

On 14/11/13 11:33, Andrew Dunstan wrote: On 11/13/2013 04:58 PM, Merlin Moncure wrote: On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan wrote: On 11/13/2013 11:37 AM, Merlin Moncure wrote: Yes. and I think this is one of the major advantages of the json API vs hstore: you can serialize objec

Re: [HACKERS] hail the CFM

On 14/11/13 02:45, Peter Eisentraut wrote: The commit fest manager mace has been passed on to me[*]. More to follow. [*] Actually, I found it behind the dumpster in the alley. Did you take care not to touch it with bare skin & properly sterilize it? As a used mace, may pick up blood from p

Re: [HACKERS] Fast insertion indexes: why no developments

On 05/11/13 05:35, Robert Haas wrote: On Mon, Nov 4, 2013 at 11:32 AM, Andres Freund wrote: I think doing this outside of s_b will make stuff rather hard for physical replication and crash recovery since we either will need to flush the whole buffer at checkpoints - which is hard since the chec

Re: [HACKERS] logical column order and physical column order

On 03/11/13 20:37, David Rowley wrote: I've just been looking at how alignment of columns in tuples can make the tuple larger than needed. I created 2 tables... None of which are very real world, but I was hunting for the extremes here... The first table contained an int primary key and then

Re: [HACKERS] Fast insertion indexes: why no developments

On 31/10/13 06:46, Jeff Janes wrote: On Wed, Oct 30, 2013 at 9:54 AM, Leonardo Francalanci mailto:m_li...@yahoo.it>> wrote: Jeff Janes wrote > The index insertions should be fast until the size of the active part of > the indexes being inserted into exceeds shared_buffers by som

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 24/10/13 12:58, Peter Geoghegan wrote: On Wed, Oct 23, 2013 at 4:48 PM, Gavin Flower wrote: 32 int64 buckets is only 256 bytes, so a thousand histograms would be less than a quarter of a MB. Any machine that busy, would likely have many GB's of RAM. I have 32 GB on my development ma

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 24/10/13 12:46, Josh Berkus wrote: On 10/23/2013 01:26 PM, Peter Geoghegan wrote: So fixing that problem would go a long way towards resolving these concerns. It would also probably have the benefit of making it possible for query texts to be arbitrarily long - we'd be storing them in files (

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 24/10/13 12:24, Peter Geoghegan wrote: On Wed, Oct 23, 2013 at 4:14 PM, Jeff Janes wrote: The last bucket would be limited to 8ms < x <= 16 ms. If you find something 16ms, then you have to rescale *before* you increment any of the buckets. Once you do, there is now room to hold it. How i

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 24/10/13 12:14, Jeff Janes wrote: On Wed, Oct 23, 2013 at 4:00 PM, Gavin Flower mailto:gavinflo...@archidevsys.co.nz>> wrote: On 24/10/13 11:26, Peter Geoghegan wrote: On Wed, Oct 23, 2013 at 2:57 PM, Gavin Flower mailto:gavinflo...@archidevsys.co.nz&g

<    1   2   3   >