Re: [HACKERS] PL/pgSQL 2

On 2014-09-02 19:33, Kevin Grittner wrote: Marko Tiikkaja wrote: Well, just off the top of my head a normal function invocation could be: one worker working on a single "order" started by a single end user to transfer money from one account to another. And we have *a lot* of code like this

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

On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote: To make the code mentioned above (Patch 0002) tidy, rewrite the socket emulation code for win32 backends so that each socket can have its own non-blocking state. (patch 0001) The first patch that makes non-blocking sockets behave more sa

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

On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote: - Preventing protocol violation. To prevent protocol violation, secure_write sets ClientConnectionLost when SIGTERM detected, then internal_flush() and ProcessInterrupts() follow the instruction. Oh, hang on. Now that I look at pqcom

Re: [HACKERS] PL/pgSQL 2

Marko Tiikkaja wrote: > Sounds like in this case you'd only use set-oriented programming > at the end of the transaction, no? I guess -- more properly I would say "in the final database transaction for that financial transaction."  And no, that never made me wish that plpgsql functions defaulted

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

On 2014-09-02 21:46:29 +0300, Heikki Linnakangas wrote: > I was going to suggest using WaitLatchOrSocket instead of sleeping in 1 > second increment, but I see that WaitLatchOrSocket() doesn't currently > support waiting for a socket to become writeable, without also waiting for > it to become read

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

On 2014-09-02 21:01:44 +0200, Andres Freund wrote: > I've actually been working on a patch to make the whole interaction with > the client using sockets. The reason I started so is that we lots of far > to complex stuff in signal handlers, and using a latch would allow us to > instead interrupt sen

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Tue, Aug 26, 2014 at 4:09 PM, Peter Geoghegan wrote: > On Tue, Aug 26, 2014 at 12:59 PM, Robert Haas wrote: >> I have committed a fix for that problem. Let me know if I missed >> something else. > > Yes, that's all I meant. OK. The patch needs another rebase as a result of that fix. In gen

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 07:06:02PM +0200, Joel Jacobson wrote: > On Tue, Sep 2, 2014 at 7:01 PM, Bruce Momjian wrote: > > On Tue, Sep 2, 2014 at 06:57:42PM +0200, Joel Jacobson wrote: > >> On Tue, Sep 2, 2014 at 6:45 PM, Bruce Momjian wrote: > >> > SINGLETON UPDATE ...? > >> > >> Does it come wi

Re: [HACKERS] Scaling shared buffer eviction

On Thu, Aug 28, 2014 at 7:11 AM, Amit Kapila wrote: > I have updated the patch to address the feedback. Main changes are: > > 1. For populating freelist, have a separate process (bgreclaimer) > instead of doing it by bgwriter. > 2. Autotune the low and high threshold values for buffers > in freel

Re: [HACKERS] PL/pgSQL 2

On 2014-09-02 19:06:02 +0200, Joel Jacobson wrote: > But what do you think about, > STRICT UPDATE ...? I quite dislike it. An UPDATE isn't less 'strict' (whatever that means) if updates more than one row. There's some sense in the way it's used for INTO because it's referring to the INTO. And it's

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

On 2014-08-29 01:00, Alvaro Herrera wrote: Vik Fearing wrote: Here are two patches for this. The first one, reindex_user_tables.v1.patch, implements the variant that only hits user tables, as suggested by you. The second one, reindex_no_dbname.v1.patch, allows the three database-wide variants

Re: [HACKERS] On partitioning

On Tue, Sep 02, 2014 at 09:44:17AM -0400, Bruce Momjian wrote: > On Sun, Aug 31, 2014 at 10:45:29PM +0200, Martijn van Oosterhout wrote: > > There is one situation where you need to be more flexible, and that is > > if you ever want to support online repartitioning. To do that you have > > to disti

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

Marko Tiikkaja wrote: > On 2014-08-29 01:00, Alvaro Herrera wrote: > >Note: I don't like the reindexdb UI; if you just run "reindexdb -d > >foobar" it will reindex everything, including system catalogs. I think > >USER TABLES should be the default operation mode for reindex. If you > >want plai

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 4:04 AM, Joel Jacobson wrote: > Hi, > > For those of you who use PL/pgSQL every day, I'm quite certain you all feel > there are a number of things you would like to change in the language, but > realize it cannot be achieved without possibly breaking compatibility, at > leas

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

On 2014-09-02 22:24, Alvaro Herrera wrote: Marko Tiikkaja wrote: Do we have some kind of an agreement on what this patch should look like? Is someone going to prepare an updated patch? Vik? I think the only issue left for this to be committable is reindexdb --all previously mentioned. I sc

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

Marko Tiikkaja wrote: > On 2014-09-02 22:24, Alvaro Herrera wrote: > >Marko Tiikkaja wrote: > >>Do we have some kind of an agreement on what this patch should look > >>like? Is someone going to prepare an updated patch? Vik? > > > >I think the only issue left for this to be committable is reindex

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas wrote: > < Various points on style> Okay, fair enough. > n_distinct is a cardinality estimate, but AFAIK not using hyperloglog. > What is different about that problem vs. this one that makes each > method correct for its respective case? Or should an

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 09:48 AM, Bruce Momjian wrote: As a case in point, EDB have spent quite a few man-years on their Oracle compatibility layer; and it's still not a terribly exact match, according to my colleagues who have looked at it. So that is a tarbaby I don't personally care to touch ... even

Re: [HACKERS] PL/pgSQL 2

Without having read the entire thread ... On 09/01/2014 05:04 AM, Joel Jacobson wrote: From the top of my head, these are Things I personally would want to see in plpgsql2: + Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1 row, as that's the most common use-case, and provi

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake wrote: > > On 09/02/2014 09:48 AM, Bruce Momjian wrote: > > As a case in point, EDB have spent quite a few man-years on their Oracle >>> compatibility layer; and it's still not a terribly exact match, according >>> to my colleagues who have looked

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 10:16 PM, Andres Freund wrote: > On 2014-09-02 19:06:02 +0200, Joel Jacobson wrote: >> But what do you think about, >> STRICT UPDATE ...? > > I quite dislike it. An UPDATE isn't less 'strict' (whatever that means) > if updates more than one row. There's some sense in the way

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 09:06 PM, Andrew Dunstan wrote: On 09/01/2014 08:09 PM, Neil Tiffin wrote: The docs also tell you how to avoid having to do this, using dollar quoting. That should be enough alone to suggest postgreSQL start working on a modern, in core, fast, fully supported language. Of cou

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

Heikki Linnakangas writes: > I was going to suggest using WaitLatchOrSocket instead of sleeping in 1 > second increment, but I see that WaitLatchOrSocket() doesn't currently > support waiting for a socket to become writeable, without also waiting > for it to become readable. I wonder how diffic

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 10:27 PM, Merlin Moncure wrote: > What is the reasoning for breaking compatibiilty? Why not improve the > language that's there? Because many suggested improvement are not possible without breaking compatibility, at least in theory. See previous posts in the thread. > whe

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 12:20 PM, Joel Jacobson wrote: On Tue, Sep 2, 2014 at 6:09 PM, Kevin Grittner wrote: Joel Jacobson wrote: Sorry for being unclear, I didn't mean to suggest the main concern is updating *all* rows. The main concern is when you have a rather complex UPDATE WHERE clause, aiming to

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

On 2014-09-02 17:21:03 -0400, Tom Lane wrote: > Heikki Linnakangas writes: > > I was going to suggest using WaitLatchOrSocket instead of sleeping in 1 > > second increment, but I see that WaitLatchOrSocket() doesn't currently > > support waiting for a socket to become writeable, without also wai

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 10:41 AM, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer wrote: Well, the idiom: EXECUTE format("SELECT %I FROM %I WHERE $1", col, tbl) USING val; is not lovely. It works, but it's clumsy. This is exactly why we need a new language. All the clumsy stuff we

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 23:11, David Johnston wrote: On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake >wrote: On 09/02/2014 09:48 AM, Bruce Momjian wrote: As a case in point, EDB have spent quite a few man-years on their Oracle compati

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 02:11 PM, David Johnston wrote: On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake mailto:j...@commandprompt.com>>wrote: On 09/02/2014 09:48 AM, Bruce Momjian wrote: As a case in point, EDB have spent quite a few man-years on their Oracle com

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 09:32 AM, Joel Jacobson wrote: I think it's much better to make it the default behaviour in plpgsql2 than to add a new syntax to plpgsql, because then we don't have to argue what to call the keyword or where to put it. This should in NO CASE be any new syntax to plpgsql or plpgsq

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 23:34, Joshua D. Drake wrote: On 09/02/2014 02:11 PM, David Johnston wrote: On Tue, Sep 2, 2014 at 4:48 PM, Joshua D. Drake mailto:j...@commandprompt.com>>wrote: On 09/02/2014 09:48 AM, Bruce Momjian wrote: As a case in point, EDB have spent quite a few man-years

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 04:16 PM, Andres Freund wrote: On 2014-09-02 19:06:02 +0200, Joel Jacobson wrote: But what do you think about, STRICT UPDATE ...? I quite dislike it. An UPDATE isn't less 'strict' (whatever that means) if updates more than one row. There's some sense in the way it's used for INTO

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 02:04 AM, Joel Jacobson wrote: > Please share your wish list of things you would want in plpgsql2 which > are not possible to implement in plpgsql because they could possibly > break compatibility. Well, if I were designing a new procedural SQL extension language, I wouldn't base it

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 03:19 PM, Josh Berkus wrote: > Well, if I were designing a new procedural SQL extension language, I > wouldn't base it on the bastard child of ADA and SQL89. I would come up Ada, that is. One is a programming language, the other is the bane of architects. -- Josh Berkus PostgreSQ

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote: Yeah, we differ there. I think having an Oracle compatibility layer in PostgreSQL would be the-next-big-thing we could have. Oracle is has orders of magnitude bigger user base than postgres has; and having the ability to attract them

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 03:19 PM, Josh Berkus wrote: On 09/01/2014 02:04 AM, Joel Jacobson wrote: Please share your wish list of things you would want in plpgsql2 which are not possible to implement in plpgsql because they could possibly break compatibility. Well, if I were designing a new procedural

Re: [HACKERS] why after increase the hash table partitions, TPMC decrease

On Tue, Sep 2, 2014 at 1:39 AM, Xiaoyulei wrote: > > > We use benchmarksql to start tpcc test in postgresql 9.3.3. > > Before test we set benchmarksql client number about 800. And we increase > the hash partitions from 16 to 1024 , in order to reduce the hash > partition locks competition. > Can

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 06:41 PM, Joshua D. Drake wrote: On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote: Yeah, we differ there. I think having an Oracle compatibility layer in PostgreSQL would be the-next-big-thing we could have. Oracle is has orders of magnitude bigger user base than postg

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 06:50 PM, Jan Wieck wrote: On 09/02/2014 06:41 PM, Joshua D. Drake wrote: On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote: Yeah, we differ there. I think having an Oracle compatibility layer in PostgreSQL would be the-next-big-thing we could have. Oracle is has ord

Re: [HACKERS] PL/pgSQL 2

On 03/09/14 00:41, Joshua D. Drake wrote: On 09/02/2014 02:47 PM, Álvaro Hernández Tortosa wrote: Yeah, we differ there. I think having an Oracle compatibility layer in PostgreSQL would be the-next-big-thing we could have. Oracle is has orders of magnitude bigger user base than postgres

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 06:56 PM, Andrew Dunstan wrote: People are free to do what they want, but to my mind that would be a massive waste of resources, and probably imposing a substantial extra maintenance burden on the core committers. I hear you and agree to some degree. But at the same time I rememb

Re: [HACKERS] Tips/advice for implementing integrated RESTful HTTP API

On 02/09/14 04:47, Dobes Vandermeer wrote: Same idea as PgBouncer or PgPool. The advantage over hacking PgBouncer/PgPool for the job is that Tomcat can already do a lot of what you want using built-in, pre-existing functionality. Connection pool management, low level REST-st

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas wrote: > Maybe we should get rid of the tiebreak case altogether: the second > SortSupport object is just containing all the same values as the first > one, with only the comparator being different. Can't we just have > both the abbreviated-comparator

Re: [HACKERS] Need Multixact Freezing Docs

On Thu, Aug 28, 2014 at 09:32:17AM -0700, Josh Berkus wrote: > On 08/28/2014 09:09 AM, Alvaro Herrera wrote: > > Josh Berkus wrote: > >> On 04/16/2014 01:30 PM, Alvaro Herrera wrote: > >>> Josh Berkus wrote: > > > You can see the current multixact value in pg_controldata output. Keep > >>

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas wrote: > That would have the > nice property of avoiding the need for special handling in > reversedirection_heap(). Oh, BTW, we probably don't need that anyway, since I'm already disabling abbreviated key optimization in the event of a bounded sort o

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 7:08 PM, Jan Wieck wrote: > On 09/02/2014 06:56 PM, Andrew Dunstan wrote: > >> People are free to do what they want, but to my mind that would be a >> massive waste of resources, and probably imposing a substantial extra >> maintenance burden on the core committers. >> > >

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Tue, Sep 2, 2014 at 12:22 PM, Robert Haas wrote: > Most places that use a SortSupportData initialize ssup.position > explicitly, but tuplesort_begin_datum() doesn't. That's an > inconsistency that should be fixed, but I'm not sure which direction > is best. I'm not sure what you mean. tupleso

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

Attached revision: * Still doesn't address the open question of whether or not we should optimistically always try "memcmp() == 0" on tiebreak. I still lean towards "yes". * Leaves open the question of what to do when we can't use the abbreviated keys optimization just because a datum tuplesort i

Re: [HACKERS] pg_upgrade and epoch

On Wed, Apr 23, 2014 at 12:41:41PM -0700, Sergey Konoplev wrote: > On Wed, Apr 23, 2014 at 5:26 AM, Bruce Momjian wrote: > > Sergey, are you seeing a problem only because you are > > interacting with other systems that didn't reset their epoch? > > I faced this after upgrading clusters with PgQ S

Re: [HACKERS] why after increase the hash table partitions, TPMC decrease

benchmarSQL has about half reads. So I think it should be effective. I don't think BufFreelistLock take much time, it just get a buffer from list. It should be very fast. The test server has 2 CPUs and 12 cores in each CPU. 24 processor totally. CPU Idle time is over 50%. IO only 10%(data is i

Re: [HACKERS] Scaling shared buffer eviction

On Thu, Aug 28, 2014 at 4:41 PM, Amit Kapila wrote: > > I have yet to collect data under varying loads, however I have > collected performance data for 8GB shared buffers which shows > reasonably good performance and scalability. > > I think the main part left for this patch is more data for vario

Re: [HACKERS] Scaling shared buffer eviction

On Wed, Sep 3, 2014 at 9:45 AM, Amit Kapila wrote: > > On Thu, Aug 28, 2014 at 4:41 PM, Amit Kapila wrote: > > > > I have yet to collect data under varying loads, however I have > > collected performance data for 8GB shared buffers which shows > > reasonably good performance and scalability. > >

Re: [HACKERS] Patch for psql History Display on MacOSX

On Tue, Sep 02, 2014 at 01:56:34AM -0400, Tom Lane wrote: > Noah Misch writes: > > On Mon, Sep 01, 2014 at 10:22:57PM -0400, Tom Lane wrote: > >> Also, as best I can tell, .psql_history files from older libedit versions > >> are not forward-compatible to current libedit versions because of the > >

Re: [HACKERS] Re: proposal: ignore null fields in not relation type composite type based constructors

Hello 2014-09-02 13:54 GMT+02:00 Jeevan Chalke : > Hi Pavel, > > it needs a redesign of original implementation, we should to change API >> to use default values with named parameters >> >> but it doesn't help too much (although it can be readable little bit more) >> >> instead row_to_json(x, f

Re: [HACKERS] Re: proposal: ignore null fields in not relation type composite type based constructors

2014-09-03 7:05 GMT+02:00 Pavel Stehule : > Hello > > > 2014-09-02 13:54 GMT+02:00 Jeevan Chalke : > > Hi Pavel, >> >> it needs a redesign of original implementation, we should to change API >>> to use default values with named parameters >>> >>> but it doesn't help too much (although it can be r

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 12:19 AM, Josh Berkus wrote: > On 09/01/2014 02:04 AM, Joel Jacobson wrote: >> Please share your wish list of things you would want in plpgsql2 which >> are not possible to implement in plpgsql because they could possibly >> break compatibility. > > Well, if I were designing

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 2:46 AM, Christopher Browne wrote: > The notion of hacking features onto plpgsql2 that mostly seem like SQL > enhancements is a waste of time. New versions of languages who change too much in a new version are doomed to fail. There are many such examples in history. Complet

Re: [HACKERS] PL/pgSQL 2

2014-09-03 7:07 GMT+02:00 Joel Jacobson : > On Wed, Sep 3, 2014 at 12:19 AM, Josh Berkus wrote: > > On 09/01/2014 02:04 AM, Joel Jacobson wrote: > >> Please share your wish list of things you would want in plpgsql2 which > >> are not possible to implement in plpgsql because they could possibly >

Re: [HACKERS] PL/pgSQL 2

On Wed, Sep 3, 2014 at 7:17 AM, Pavel Stehule wrote: > yes, but there is minimal agreement of direction of movement. I am not alone > who are thinking so your proposal is not good for general usage. Minimal agreement? That's not true. The other group of users have been discussing a completely new

Re: [HACKERS] ALTER TABLESPACE MOVE command tag tweak

On Fri, Aug 22, 2014 at 8:14 AM, Stephen Frost wrote: > Alvaro, > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: >> ALTER TABLE ALL IN TABLESPACE xyz >> which AFAICS should work since ALL is already a reserved keyword. > > Pushed to master and REL9_4_STABLE. You seem to have forgotten to up

Re: [HACKERS] pg_upgrade and epoch

On Tue, Sep 2, 2014 at 7:59 PM, Bruce Momjian wrote: > On Wed, Apr 23, 2014 at 12:41:41PM -0700, Sergey Konoplev wrote: >> On Wed, Apr 23, 2014 at 5:26 AM, Bruce Momjian wrote: >> > Sergey, are you seeing a problem only because you are >> > interacting with other systems that didn't reset their e

Re: [HACKERS] ALTER TABLESPACE MOVE command tag tweak

Fujii, * Fujii Masao (masao.fu...@gmail.com) wrote: > You seem to have forgotten to update tab-complete.c. Good point, absolutely correct. I have a bad tendency to do that. > Attached patch updates that. Many thanks, will review and apply soon. Thanks again! Stephen

Re: [HACKERS] Patch for psql History Display on MacOSX

On Tue, Sep 02, 2014 at 09:49:56AM -0400, Tom Lane wrote: > Noah Misch writes: > > I'm with you that far. Given a patch that does not change "\s /tmp/foo" and > > that makes "\s" equivalent to "\s /tmp/foo" + "\! cat /tmp/foo >/dev/tty", > > back-patch by all means. No patch posted on this threa

Re: [HACKERS] PL/pgSQL 2

2014-09-03 7:23 GMT+02:00 Joel Jacobson : > On Wed, Sep 3, 2014 at 7:17 AM, Pavel Stehule > wrote: > > yes, but there is minimal agreement of direction of movement. I am not > alone > > who are thinking so your proposal is not good for general usage. > > Minimal agreement? That's not true. The ot

Re: [HACKERS] PL/pgSQL 2

On 3 September 2014 01:08, Jan Wieck wrote: > On 09/02/2014 06:56 PM, Andrew Dunstan wrote: > >> People are free to do what they want, but to my mind that would be a >> massive waste of resources, and probably imposing a substantial extra >> maintenance burden on the core committers. >> > > I hea

<    1   2