Re: [HACKERS] Stating the significance of Lehman & Yao in the nbtree README

On Fri, Sep 26, 2014 at 11:34 PM, Amit Kapila wrote: > I have observed that this patch is in 'Needs Review' state for > next CF. Do you expect any further review from myside? I think > we can use text recommended by Heikki and after that if you > feel something more is still required, then you c

Re: [HACKERS] Stating the significance of Lehman & Yao in the nbtree README

On Fri, Sep 12, 2014 at 10:54 PM, Peter Geoghegan wrote: > > It isn't. It's a minor point, originally raised by Amit. I have observed that this patch is in 'Needs Review' state for next CF. Do you expect any further review from myside? I think we can use text recommended by Heikki and after tha

Re: [HACKERS] a fast bloat measurement tool (was Re: Measuring relation free space)

On Wed, Sep 24, 2014 at 2:26 PM, Abhijit Menon-Sen wrote: > > Hi Amit. > > Thanks for your comments, and I'm sorry it's taken me so long to > respond. No issues. > At 2014-08-03 11:18:57 +0530, amit.kapil...@gmail.com wrote: > > 7. > > HeapTupleSatisfiesVacuumNoHint() > > a. Why can't we use He

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. Not really feasible

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

On Fri, Sep 26, 2014 at 11:47 AM, Alvaro Herrera wrote: > 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. > > Feasible

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

All, So these results have become a bit complex. So spreadsheet time. https://docs.google.com/spreadsheets/d/1Mokpx3EqlbWlFDIkF9qzpM7NneN9z-QOXWSzws3E-R4 Some details: The Length-and-Offset test was performed using a more recent 9.4 checkout than the other two tests. This was regrettable, and

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

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. Not really feasible without a major overhaul. It might be m

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

On Fri, Sep 26, 2014 at 3:25 PM, Peter Geoghegan wrote: > On Fri, Sep 26, 2014 at 3:11 PM, Alvaro Herrera > wrote: >> FWIW there are 28 callers of HeapTupleHeaderGetXmin. > Don't forget about direct callers to HeapTupleHeaderGetRawXmin(), > though. There are plenty of those in tqual.c. Which re

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Friday, September 26, 2014, Alvaro Herrera wrote: > David Johnston wrote: > > On Friday, September 26, 2014, Alvaro Herrera > > > wrote: > > > > > Tom Lane wrote: > > > > > > > The impression I had was that Stephen was thinking of actually > setting > > > > min_val to 1 (or whatever) and hand

Re: [HACKERS] proposal: rounding up time value less than its unit.

On 9/26/14, 2:50 PM, David G Johnston wrote: Like I said I just want to fix the bug and call it a day :) I'm afraid you've come to the wrong project and mailing list for *that*. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

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

On Fri, Sep 26, 2014 at 3:11 PM, Alvaro Herrera wrote: > FWIW there are 28 callers of HeapTupleHeaderGetXmin. 31 by my count, though that difference hardly matters. A lot of those callers are in parts of the code that I don't know well. For example, CheckForSerializableConflictOut(). Don't forge

Re: [HACKERS] pg_background (and more parallelism infrastructure patches)

On Sat, Sep 20, 2014 at 3:03 AM, Amit Kapila wrote: > Okay, but as there is no predictability (it can be either same as what > launching process has at the when it has launched background worker > or it could be some different value if got changed later due to sighup) > which GUC value will be use

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

Peter Geoghegan wrote: > Can you really say that you won't have serious misgivings > about something like the "tuple->xmin = InvalidTransactionId" > swapping, if I actually formally propose it? That's very invasive to a > lot of places. And right now, I have no idea how we could do better. FWIW t

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

On Fri, Sep 26, 2014 at 5:58 AM, Heikki Linnakangas wrote: >> And the reason that the buffer locking approach in the overlapping case >> is that you'd need to hold a large number of pages locked at the same >> time. Right? > > > Yeah, you would. To be honest, I didn't even think about the overlapp

Re: [HACKERS] Replication identifiers, take 3

On 2014-09-26 14:57:12 -0400, Robert Haas wrote: > On Fri, Sep 26, 2014 at 12:32 PM, Andres Freund > wrote: > >> Huh? That's just to say that the unused bit space is, in fact, > >> unused. But so what? We've always been very careful about using up > >> things like infomask bits, because there

Re: [HACKERS] proposal: rounding up time value less than its unit.

David Johnston wrote: > On Friday, September 26, 2014, Alvaro Herrera > wrote: > > > Tom Lane wrote: > > > > > The impression I had was that Stephen was thinking of actually setting > > > min_val to 1 (or whatever) and handling zero or -1 in some out-of-band > > > fashion, perhaps by adding GUC f

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

On Fri, Sep 26, 2014 at 5:24 AM, Heikki Linnakangas wrote: > Just to be clear: I wrote the initial patch to demonstrate what I had in > mind, because I was not able to explain it well enough otherwise. You > pointed out issues with it, which I then fixed. You then pointed out more > issues, which

Re: [HACKERS] jsonb generator functions

On 09/26/2014 05:00 PM, Peter Geoghegan wrote: On Fri, Sep 26, 2014 at 1:54 PM, Andrew Dunstan wrote: Here is a patch for the generator and aggregate functions for jsonb that we didn't manage to get done in time for 9.4. That's cool, but I hope someone revisits adding a concatenate operator.

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Friday, September 26, 2014, Alvaro Herrera wrote: > Tom Lane wrote: > > > The impression I had was that Stephen was thinking of actually setting > > min_val to 1 (or whatever) and handling zero or -1 in some out-of-band > > fashion, perhaps by adding GUC flag bits showing those as allowable >

Re: [HACKERS] proposal: rounding up time value less than its unit.

Tom Lane wrote: > The impression I had was that Stephen was thinking of actually setting > min_val to 1 (or whatever) and handling zero or -1 in some out-of-band > fashion, perhaps by adding GUC flag bits showing those as allowable > special cases. I'm not sure how we would display such a state o

Re: [HACKERS] jsonb generator functions

On Fri, Sep 26, 2014 at 1:54 PM, Andrew Dunstan wrote: > Here is a patch for the generator and aggregate functions for jsonb that we > didn't manage to get done in time for 9.4. That's cool, but I hope someone revisits adding a concatenate operator. That's a biggest omission IMHO. I'm not going

[HACKERS] jsonb generator functions

Here is a patch for the generator and aggregate functions for jsonb that we didn't manage to get done in time for 9.4. They are all equivalents of the similarly names json functions. Included are to_jsonb jsonb_build_object jsonb_build_array jsonb_object jsonb_agg json

Re: [HACKERS] proposal: rounding up time value less than its unit.

* Tom Lane (t...@sss.pgh.pa.us) wrote: > > There are others where min_val is -1 for the same reason, where > > functionally the minimum is really 0. Some of us would like to see > > min_val reflect the useful minimum, period, and move all these special > > case ones out of there. That is a mul

Re: [HACKERS] proposal: rounding up time value less than its unit.

Gregory Smith writes: > On 9/26/14, 2:34 PM, David Johnston wrote: >> ​ I don't get where we "need" to do anything else besides that...the >> whole "actual min values" comment is unclear to me. > If you look at pg_settings, there is a minimum value exposed there as > min_val. For some of the

Re: [HACKERS] proposal: rounding up time value less than its unit.

On 9/26/14, 2:34 PM, David Johnston wrote: ​ I don't get where we "need" to do anything else besides that...the whole "actual min values" comment is unclear to me. If you look at pg_settings, there is a minimum value exposed there as min_val. For some of these parameters, that number would

Re: [HACKERS] Replication identifiers, take 3

On Fri, Sep 26, 2014 at 12:32 PM, Andres Freund wrote: >> Huh? That's just to say that the unused bit space is, in fact, >> unused. But so what? We've always been very careful about using up >> things like infomask bits, because there are only so many bits >> available, and when they're gone th

Re: [HACKERS] proposal: rounding up time value less than its unit.

On 9/26/14, 2:17 PM, Tom Lane wrote: Well, ok, let's allow zero as a special case, but it has to be written as "0" not something else. If you try to set a positive value then we should act as though the min_val is 1 unit. So I'm coming around to the idea that "throw an error if a nonzero input

Re: [HACKERS] proposal: rounding up time value less than its unit.

On 09/26/2014 11:17 AM, Tom Lane wrote: > So I'm coming around to the idea that "throw an error if a nonzero > input would round (or truncate) to zero" is a reasonable solution. > I think it'd be even more reasonable if we also fixed the rounding > rule to be "round to nearest", but the two changes

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Fri, Sep 26, 2014 at 2:39 PM, Stephen Frost [via PostgreSQL] < ml-node+s1045698n5820714...@n5.nabble.com> wrote: > David, > > * David Johnston ([hidden email] > ) wrote: > > ​This is 9.5 material because 1) it isn't all that critical and, 2)

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

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. Feasible: no. Useful: maybe, we don't really know. (You could just as well h

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] proposal: rounding up time value less than its unit.

David, * David Johnston (david.g.johns...@gmail.com) wrote: > ​This is 9.5 material because 1) it isn't all that critical and, 2) we DO > NOT want a system to not come up because of a GUC paring error after a > minor-release update. Agreed. > ​I don't get where we "need" to do anything else besi

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Fri, Sep 26, 2014 at 2:27 PM, Stephen Frost wrote: > > Agreed- they're independent considerations and the original concern was > about the nonzero-to-zero issue, so I'd suggest we address that first, > though in doing so we will need to consider what *actual* min values we > should have for so

Re: [HACKERS] proposal: rounding up time value less than its unit.

Stephen Frost writes: > Agreed- they're independent considerations and the original concern was > about the nonzero-to-zero issue, so I'd suggest we address that first, > though in doing so we will need to consider what *actual* min values we > should have for some cases which currently allow goin

Re: [HACKERS] proposal: rounding up time value less than its unit.

* Tom Lane (t...@sss.pgh.pa.us) wrote: > I've been thinking more about this, and I think I'm about ready to > change my position on it: why shouldn't we error out if the value > is too small? If we believe that a GUC's unit is reasonably chosen, > then it's not sensible to try to set the value to

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Fri, Sep 26, 2014 at 2:02 PM, Robert Haas wrote: > On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote: > > Robert Haas writes: > >> If we want the narrowest possible fix for this, I think it's "complain > >> if a non-zero value would round to zero". That fixes the original > >> complaint and c

Re: [HACKERS] proposal: rounding up time value less than its unit.

David Johnston writes: > On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote: >> I apparently have got to make this point one more time: if the user >> cares about the difference between 30sec and 1min, then we erred in >> designing the GUC in question; it should have had a smaller unit. >> I am comp

Re: [HACKERS] Escaping from blocked send() reprised.

On 09/09/2014 01:31 PM, Kyotaro HORIGUCHI wrote: Hi, I added and edited some comments. Sorry, It tha patch contains a silly bug. Please find the attatched one. I must say this scares the heck out of me. The current code goes through some trouble to not throw an error while in a recv() send()

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote: > Robert Haas writes: >> If we want the narrowest possible fix for this, I think it's "complain >> if a non-zero value would round to zero". That fixes the original >> complaint and changes absolutely nothing else. But I think that's >> kind of w

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote: > Robert Haas writes: > > If we want the narrowest possible fix for this, I think it's "complain > > if a non-zero value would round to zero". That fixes the original > > complaint and changes absolutely nothing else. But I think that's > > kind

Re: [HACKERS] proposal: rounding up time value less than its unit.

* Josh Berkus (j...@agliodbs.com) wrote: > On 09/26/2014 10:27 AM, Stephen Frost wrote: > > I don't think anyone is argueing that we should do away with the > > rounding rules entirely, only that we should a) require units to be > > specified, and b) error if the value specified is below '1 unit',

Re: [HACKERS] proposal: rounding up time value less than its unit.

On 09/26/2014 10:27 AM, Stephen Frost wrote: > I don't think anyone is argueing that we should do away with the > rounding rules entirely, only that we should a) require units to be > specified, and b) error if the value specified is below '1 unit', but > still non-zero, as it would then be rounded

Re: [HACKERS] proposal: rounding up time value less than its unit.

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > If we want the narrowest possible fix for this, I think it's "complain > > if a non-zero value would round to zero". That fixes the original > > complaint and changes absolutely nothing else. But I think that's > > kind of wu

Re: [HACKERS] proposal: rounding up time value less than its unit.

Robert Haas writes: > If we want the narrowest possible fix for this, I think it's "complain > if a non-zero value would round to zero". That fixes the original > complaint and changes absolutely nothing else. But I think that's > kind of wussy. Yeah, rounding 29 seconds down to a special magic

Re: [HACKERS] Replication identifiers, take 3

On 2014-09-26 11:02:16 -0400, Robert Haas wrote: > On Fri, Sep 26, 2014 at 10:55 AM, Andres Freund > wrote: > > On 2014-09-26 10:40:37 -0400, Robert Haas wrote: > >> On Fri, Sep 26, 2014 at 10:21 AM, Andres Freund > >> wrote: > >> > As explained above this isn't happening on the level of indivi

Re: [HACKERS] Inefficient barriers on solaris with sun cc

26.09.2014, 17:28, Robert Haas kirjoitti: On Fri, Sep 26, 2014 at 8:55 AM, Oskari Saarenmaa wrote: So you think a read barrier is the same thing as an acquire barrier and a write barrier is the same as a release barrier? That would be surprising. It's certainly not true in general. The abov

Re: [HACKERS] BRIN indexes - TRAP: BadArgument

On Tue, September 23, 2014 21:04, Alvaro Herrera wrote: > Alvaro Herrera wrote: > > [minmax-19.patch] > [minmax-19a.patch] Although admittedly it is not directly likely for us to need it, and although I see that there is a BRIN Extensibility chapter added (good!), I am still a bit surprised by th

Re: [HACKERS] WITH CHECK and Column-Level Privileges

* Stephen Frost (sfr...@snowman.net) wrote: > * Stephen Frost (sfr...@snowman.net) wrote: > > > Is there similar problems with unique or exclusion constraints? > > > > That's certainly an excellent question.. I'll have to go look. > > Looks like there is an issue here with CHECK constraints and

Re: [HACKERS] WITH CHECK and Column-Level Privileges

* Stephen Frost (sfr...@snowman.net) wrote: > > Is there similar problems with unique or exclusion constraints? > > That's certainly an excellent question.. I'll have to go look. Looks like there is an issue here with CHECK constraints and NOT NULL constraints, yes. The uniqueness check complai

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Fri, Sep 26, 2014 at 10:58 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Thu, Sep 25, 2014 at 4:49 PM, Stephen Frost wrote: >> > * Gregory Smith (gregsmithpg...@gmail.com) wrote: >> >> On 9/25/14, 2:02 PM, Peter Eisentraut wrote: >> >> >But having the same param

Re: [HACKERS] WITH CHECK and Column-Level Privileges

* Heikki Linnakangas (hlinnakan...@vmware.com) wrote: > On 09/26/2014 05:20 PM, Stephen Frost wrote: > > Note that the entire failing tuple is returned, including the > > 'password' column, even though the 'alice' user does not have select > > rights on that column. > > Is there similar prob

Re: [HACKERS] WITH CHECK and Column-Level Privileges

On 09/26/2014 05:20 PM, Stephen Frost wrote: All, Through continued testing, we've discovered an issue in the WITH CHECK OPTION code when it comes to column-level privileges which impacts 9.4. It's pretty straight-forward, thankfully, but: postgres=# create view myview postgres-# w

Re: [HACKERS] Replication identifiers, take 3

On Fri, Sep 26, 2014 at 10:55 AM, Andres Freund wrote: > On 2014-09-26 10:40:37 -0400, Robert Haas wrote: >> On Fri, Sep 26, 2014 at 10:21 AM, Andres Freund >> wrote: >> > As explained above this isn't happening on the level of individual AMs. >> >> Well, that's even worse. You want to grab 100

Re: [HACKERS] proposal: rounding up time value less than its unit.

On Thu, Sep 25, 2014 at 4:49 PM, Stephen Frost wrote: > * Gregory Smith (gregsmithpg...@gmail.com) wrote: >> On 9/25/14, 2:02 PM, Peter Eisentraut wrote: >> >But having the same parameter setting mean different things in >> >different versions is the path to complete madness. >> >> Could we go so

[HACKERS] json (b) and null fields

I should have been paying a bit more attention to the recent work on adding an ignore_nulls option to row_to_json(). Here are some belated thought. I apologize to Pavel and Stephen for not having commented earlier. I think this is really a bandaid, and it will fail to catch lots of cases. Seve

Re: [HACKERS] proposal: rounding up time value less than its unit.

* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Sep 25, 2014 at 4:49 PM, Stephen Frost wrote: > > * Gregory Smith (gregsmithpg...@gmail.com) wrote: > >> On 9/25/14, 2:02 PM, Peter Eisentraut wrote: > >> >But having the same parameter setting mean different things in > >> >different versions

Re: [HACKERS] Replication identifiers, take 3

On 2014-09-26 10:40:37 -0400, Robert Haas wrote: > On Fri, Sep 26, 2014 at 10:21 AM, Andres Freund > wrote: > > As explained above this isn't happening on the level of individual AMs. > > Well, that's even worse. You want to grab 100% of the available > generic bitspace applicable to all record

Re: [HACKERS] RLS feature has been committed

On Fri, Sep 26, 2014 at 5:12 AM, Simon Riggs wrote: > On 26 September 2014 08:48, Heikki Linnakangas > wrote: >> But in many cases, lack of good documentation makes even reviewing the patch >> difficult. How do you determine if the patch works as intended, if you don't >> know what it's supposed

Re: [HACKERS] Sloppy thinking about leakproof properties of opclass co-members

* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Sep 24, 2014 at 5:34 PM, Tom Lane wrote: > > ISTM that the most appropriate solution here is to insist that all or none > > of the members of an operator class be marked leakproof. (Possibly we > > could restrict that to btree opclasses, but

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

On Fri, Sep 26, 2014 at 7:06 PM, 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

Re: [HACKERS] Scaling shared buffer eviction

On 2014-09-26 09:59:41 -0400, Robert Haas wrote: > On Fri, Sep 26, 2014 at 8:26 AM, Andres Freund wrote: > > Neither, really. The hash calculation is visible in the profile, but not > > that pronounced yet. The primary thing noticeable in profiles (besides > > cache efficiency) is the comparison o

Re: [HACKERS] Replication identifiers, take 3

On Fri, Sep 26, 2014 at 10:21 AM, Andres Freund wrote: > As explained above this isn't happening on the level of individual AMs. Well, that's even worse. You want to grab 100% of the available generic bitspace applicable to all record types for purposes specific to logical decoding (and it's sti

Re: [HACKERS] Scaling shared buffer eviction

On 2014-09-26 16:47:55 +0300, Heikki Linnakangas wrote: > On 09/26/2014 03:26 PM, Andres Freund wrote: > >On 2014-09-26 15:04:54 +0300, Heikki Linnakangas wrote: > >>On 09/25/2014 05:40 PM, Andres Freund wrote: > >>>There's two reasons for that: a) dynahash just isn't very good and it > >>>does a l

Re: [HACKERS] Scaling shared buffer eviction

On 2014-09-26 17:01:52 +0300, Ants Aasma wrote: > On Fri, Sep 26, 2014 at 3:26 PM, Andres Freund wrote: > > Neither, really. The hash calculation is visible in the profile, but not > > that pronounced yet. The primary thing noticeable in profiles (besides > > cache efficiency) is the comparison of

Re: [HACKERS] Scaling shared buffer eviction

On Fri, Sep 26, 2014 at 7:04 PM, Robert Haas wrote: > On Fri, Sep 26, 2014 at 7:40 AM, Amit Kapila > wrote: > >> First of all thanks for committing part-1 of this changes and it >> seems you are planing to commit part-3 based on results of tests >> which Andres is planing to do and for remaining

Re: [HACKERS] Inefficient barriers on solaris with sun cc

On Fri, Sep 26, 2014 at 8:55 AM, Oskari Saarenmaa wrote: >> So you think a read barrier is the same thing as an acquire barrier >> and a write barrier is the same as a release barrier? That would be >> surprising. It's certainly not true in general. > > The above doc describes the difference: re

Re: [HACKERS] Replication identifiers, take 3

On 2014-09-26 09:53:09 -0400, Robert Haas wrote: > On Fri, Sep 26, 2014 at 5:05 AM, Andres Freund wrote: > >> Let me try to summarize the information requirements for each of these > >> things. For #1, you need to know, after crash recovery, for each > >> standby, the last commit LSN which the cl

[HACKERS] WITH CHECK and Column-Level Privileges

All, Through continued testing, we've discovered an issue in the WITH CHECK OPTION code when it comes to column-level privileges which impacts 9.4. It's pretty straight-forward, thankfully, but: postgres=# create view myview postgres-# with (security_barrier = true, postgres-# check_opti

Re: [HACKERS] Scaling shared buffer eviction

On Fri, Sep 26, 2014 at 3:26 PM, Andres Freund wrote: > Neither, really. The hash calculation is visible in the profile, but not > that pronounced yet. The primary thing noticeable in profiles (besides > cache efficiency) is the comparison of the full tag after locating a > possible match in a buc

Re: [HACKERS] Scaling shared buffer eviction

On Fri, Sep 26, 2014 at 8:26 AM, Andres Freund wrote: > Neither, really. The hash calculation is visible in the profile, but not > that pronounced yet. The primary thing noticeable in profiles (besides > cache efficiency) is the comparison of the full tag after locating a > possible match in a buc

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

On 2014-09-26 15:58:17 +0300, Heikki Linnakangas wrote: > On 09/26/2014 03:40 PM, Andres Freund wrote: > >And the reason that the buffer locking approach in the overlapping case > >is that you'd need to hold a large number of pages locked at the same > >time. Right? > > Yeah, you would. To be hone

Re: [HACKERS] Replication identifiers, take 3

On Fri, Sep 26, 2014 at 5:05 AM, Andres Freund wrote: >> Let me try to summarize the information requirements for each of these >> things. For #1, you need to know, after crash recovery, for each >> standby, the last commit LSN which the client has confirmed via a >> feedback message. > > I'm not

Re: [HACKERS] Scaling shared buffer eviction

On 09/26/2014 03:26 PM, Andres Freund wrote: On 2014-09-26 15:04:54 +0300, Heikki Linnakangas wrote: On 09/25/2014 05:40 PM, Andres Freund wrote: There's two reasons for that: a) dynahash just isn't very good and it does a lot of things that will never be necessary for these hashes. b) the key

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

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 presume > will normally be the case). C

Re: [HACKERS] Scaling shared buffer eviction

On Fri, Sep 26, 2014 at 7:40 AM, Amit Kapila wrote: > First of all thanks for committing part-1 of this changes and it > seems you are planing to commit part-3 based on results of tests > which Andres is planing to do and for remaining part (part-2), today > I have tried some tests, the results o

Re: [HACKERS] Inefficient barriers on solaris with sun cc

On 2014-09-26 08:39:38 -0400, Robert Haas wrote: > On Fri, Sep 26, 2014 at 8:36 AM, Oskari Saarenmaa wrote: > > 25.09.2014, 16:34, Andres Freund kirjoitti: > >> Binaries compiled on solaris using sun studio cc currently don't have > >> compiler and memory barriers implemented. That means we fall b

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

On 09/26/2014 03:40 PM, Andres Freund wrote: On 2014-09-26 15:32:35 +0300, Heikki Linnakangas wrote: On 09/26/2014 03:30 PM, Andres Freund wrote: On 2014-09-26 15:24:21 +0300, Heikki Linnakangas wrote: I don't know what you mean by "in the head of AM", but IMO it would be far better if we can

Re: [HACKERS] GIN improvements part2: fast scan

On 09/25/2014 09:05 PM, Thom Brown wrote: On 12 March 2014 16:29, Heikki Linnakangas wrote: Good point. We have done two major changes to GIN in this release cycle: changed the data page format and made it possible to skip items without fetching all the keys ("fast scan"). gincostestimate doesn

Re: [HACKERS] Inefficient barriers on solaris with sun cc

26.09.2014, 15:39, Robert Haas kirjoitti: On Fri, Sep 26, 2014 at 8:36 AM, Oskari Saarenmaa wrote: 25.09.2014, 16:34, Andres Freund kirjoitti: Binaries compiled on solaris using sun studio cc currently don't have compiler and memory barriers implemented. That means we fall back to relatively s

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

On 2014-09-26 15:32:35 +0300, Heikki Linnakangas wrote: > On 09/26/2014 03:30 PM, Andres Freund wrote: > >On 2014-09-26 15:24:21 +0300, Heikki Linnakangas wrote: > >>I don't know what you mean by "in the head of AM", but IMO it would be far > >>better if we can implement this outside the index AMs.

Re: [HACKERS] Inefficient barriers on solaris with sun cc

On Fri, Sep 26, 2014 at 8:36 AM, Oskari Saarenmaa wrote: > 25.09.2014, 16:34, Andres Freund kirjoitti: >> Binaries compiled on solaris using sun studio cc currently don't have >> compiler and memory barriers implemented. That means we fall back to >> relatively slow generic implementations for tho

Re: [HACKERS] Inefficient barriers on solaris with sun cc

25.09.2014, 16:34, Andres Freund kirjoitti: Binaries compiled on solaris using sun studio cc currently don't have compiler and memory barriers implemented. That means we fall back to relatively slow generic implementations for those. Especially compiler, read, write barriers will be much slower t

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

On 09/26/2014 03:30 PM, Andres Freund wrote: On 2014-09-26 15:24:21 +0300, Heikki Linnakangas wrote: I don't know what you mean by "in the head of AM", but IMO it would be far better if we can implement this outside the index AMs. Then it will work with any index AM. Also, it's the only chance

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

On 2014-09-26 15:24:21 +0300, Heikki Linnakangas wrote: > I don't know what you mean by "in the head of AM", but IMO it would be far > better if we can implement this outside the index AMs. Then it will work > with any index AM. Also, it's the only chance to make this ever work across partitions.

Re: [HACKERS] Scaling shared buffer eviction

On 2014-09-26 15:04:54 +0300, Heikki Linnakangas wrote: > On 09/25/2014 05:40 PM, Andres Freund wrote: > >There's two reasons for that: a) dynahash just isn't very good and it > >does a lot of things that will never be necessary for these hashes. b) > >the key into the hash table is*far* too wide.

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

On 09/26/2014 12:13 AM, Peter Geoghegan wrote: On Thu, Sep 25, 2014 at 1:48 PM, Simon Riggs wrote: C. Internal weirdness Submit C based upon earlier agreed B, submit to Dec 15 CF, major patch deadline, so we can fine tune for last CF. Then Heikki rewrites half your patch in a better way, you th

Re: [HACKERS] delta relations in AFTER triggers

On 09/25/2014 06:54 PM, Kevin Grittner wrote: Heikki Linnakangas wrote: You cast the TuplestoreRelation to Plan, and pass it to CopyPlanFields. That will crash, because TuplestoreRelation is nothing like a Plan: Oops. That's a copy/paste error I should have noticed. Fixed, even though the

Re: [HACKERS] Scaling shared buffer eviction

On 09/25/2014 05:40 PM, Andres Freund wrote: There's two reasons for that: a) dynahash just isn't very good and it does a lot of things that will never be necessary for these hashes. b) the key into the hash table is*far* too wide. A significant portion of the time is spent comparing buffer/lock

Re: [HACKERS] Scaling shared buffer eviction

On Tue, Sep 23, 2014 at 10:31 AM, Robert Haas wrote: > > But this gets at another point: the way we're benchmarking this right > now, we're really conflating the effects of three different things: > > 1. Changing the locking regimen around the freelist and clocksweep. > 2. Adding a bgreclaimer pr

Re: [HACKERS] Replication identifiers, take 3

On 2014-09-25 22:44:49 -0400, Robert Haas wrote: > Thanks for this write-up. > > On Tue, Sep 23, 2014 at 2:24 PM, Andres Freund wrote: > > 1) The ability Monitor how for replication has progressed in a > >crashsafe manner to allow it to restart at the right point after > >errors/crashes. >

Re: [HACKERS] Replication identifiers, take 3

On 26/09/14 04:44, Robert Haas wrote: On Tue, Sep 23, 2014 at 2:24 PM, Andres Freund wrote: Note that it depends on the replication solution whether these external identifiers need to be coordinated across systems or not. I think it's *good* if we don't propose a solution for that - different

Re: [HACKERS] RLS feature has been committed

On 26 September 2014 08:48, Heikki Linnakangas wrote: > But in many cases, lack of good documentation makes even reviewing the patch > difficult. How do you determine if the patch works as intended, if you don't > know what it's supposed to do? Exactly. Lack of review and lack of consensus are

Re: [HACKERS] [GENERAL] [SQL] pg_multixact issues

On Fri, Sep 19, 2014 at 1:23 PM, Dev Kumkar wrote: > Apologies for the delay, was working/troubleshooting same issue and was > away from my emails. :( > Regards... > Received the database with huge pg_multixact directory of size 21G and there are ~82,000 files in "pg_multixact/members" and 202 f

Re: [HACKERS] RLS feature has been committed

On 09/26/2014 01:07 AM, Stephen Frost wrote: * Simon Riggs (si...@2ndquadrant.com) wrote: My major reason to revert is the following: the documentation contains no examples of real world usage, making the feature essentially unusable out of the box. I find this to be an interesting argument co

Re: [HACKERS] copy & pastos in atomics.h comments

On 2014-09-26 09:18:08 +0200, Erik Rijkers wrote: > the the (6x) Gah. I thought I'd fixed the one Heikki had noticed, but apparently it was a independent one. Thanks for watching/fixing. Pushed. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ Postgre

[HACKERS] copy & pastos in atomics.h comments

the the (6x) --- src/include/port/atomics.h.orig 2014-09-26 09:06:10.553635053 +0200 +++ src/include/port/atomics.h 2014-09-26 09:07:14.763579885 +0200 @@ -346,7 +346,7 @@ /* * pg_atomic_fetch_add_u32 - atomically add to variable * - * Returns the the value of ptr before the arithmetic opera