Re: [HACKERS] Anonymous code block with parameters

Hi 2014-09-16 8:38 GMT+02:00 Kalyanov Dmitry : > I'd like to propose support for IN and OUT parameters in 'DO' blocks. > > Currently, anonymous code blocks (DO statements) can not receive or > return parameters. > > I suggest: > > 1) Add a new clause to DO statement for specifying names, types, >

Re: [HACKERS] Collation-aware comparisons in GIN opclasses

On Mon, Sep 15, 2014 at 11:45 PM, Tom Lane wrote: > Peter Geoghegan writes: > > On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov > > wrote: > >> Rename such opclasses and make them not default. > >> Create new default opclasses with bitwise comparison functions. > >> Write recommendation to

Re: [HACKERS] Anonymous code block with parameters

On 09/16/2014 09:38 AM, Kalyanov Dmitry wrote: I'd like to propose support for IN and OUT parameters in 'DO' blocks. Currently, anonymous code blocks (DO statements) can not receive or return parameters. I suggest: 1) Add a new clause to DO statement for specifying names, types, directions and

Re: [HACKERS] Anonymous code block with parameters

2014-09-16 9:10 GMT+02:00 Heikki Linnakangas : > On 09/16/2014 09:38 AM, Kalyanov Dmitry wrote: > >> I'd like to propose support for IN and OUT parameters in 'DO' blocks. >> >> Currently, anonymous code blocks (DO statements) can not receive or >> return parameters. >> >> I suggest: >> >> 1) Add a

Re: [HACKERS] Anonymous code block with parameters

On 09/16/2014 10:15 AM, Pavel Stehule wrote: 2014-09-16 9:10 GMT+02:00 Heikki Linnakangas : On 09/16/2014 09:38 AM, Kalyanov Dmitry wrote: I'd like to propose support for IN and OUT parameters in 'DO' blocks. Currently, anonymous code blocks (DO statements) can not receive or return paramete

Re: [HACKERS] Anonymous code block with parameters

On 09/16/2014 09:15 AM, Pavel Stehule wrote: > > > 2014-09-16 9:10 GMT+02:00 Heikki Linnakangas >: > > On 09/16/2014 09:38 AM, Kalyanov Dmitry wrote: > > I'd like to propose support for IN and OUT parameters in 'DO' > blocks. > > Currentl

Re: [HACKERS] Collation-aware comparisons in GIN opclasses

> No. And we don't know how to change the default opclass without > breaking things, either. See previous discussions about how we > might fix the totally-broken default gist opclass that btree_gist > creates for the inet type [1]. The motivation for getting rid of that > is *way* stronger than

Re: [HACKERS] Collation-aware comparisons in GIN opclasses

On Tue, Sep 16, 2014 at 11:29 AM, Emre Hasegeli wrote: > Changing the default opclasses should work if we make > pg_dump --binary-upgrade dump the default opclasses with indexes > and exclusion constraints. I think it makes sense to do so in > --binary-upgrade mode. I can try to come with a pat

Re: [HACKERS] Anonymous code block with parameters

2014-09-16 9:24 GMT+02:00 Heikki Linnakangas : > On 09/16/2014 10:15 AM, Pavel Stehule wrote: > >> 2014-09-16 9:10 GMT+02:00 Heikki Linnakangas : >> >> On 09/16/2014 09:38 AM, Kalyanov Dmitry wrote: >>> >>> I'd like to propose support for IN and OUT parameters in 'DO' blocks. Currently

Re: [HACKERS] Anonymous code block with parameters

On 09/16/2014 10:44 AM, Pavel Stehule wrote: 2014-09-16 9:24 GMT+02:00 Heikki Linnakangas : On 09/16/2014 10:15 AM, Pavel Stehule wrote: Why we don't introduce a temporary functions instead? You can already do that: create function pg_temp.tempfunc(i int4) returns int4 as $$ begin end; $$

Re: [HACKERS] Anonymous code block with parameters

On 09/16/2014 03:15 PM, Pavel Stehule wrote: > Why we don't introduce a temporary functions instead? I think that'd be a lot cleaner and simpler. It's something I've frequently wanted, and as Hekki points out it's already possible by creating the function in pg_temp, there just isn't the syntax s

Re: [HACKERS] Anonymous code block with parameters

On 09/16/2014 09:44 AM, Pavel Stehule wrote: > > > 2014-09-16 9:24 GMT+02:00 Heikki Linnakangas >: > > On 09/16/2014 10:15 AM, Pavel Stehule wrote: > > 2014-09-16 9:10 GMT+02:00 Heikki Linnakangas > mailto:hlinnakan...@vmware.com>>: > >

Re: [HACKERS] Anonymous code block with parameters

2014-09-16 9:58 GMT+02:00 Heikki Linnakangas : > On 09/16/2014 10:44 AM, Pavel Stehule wrote: > >> 2014-09-16 9:24 GMT+02:00 Heikki Linnakangas : >> >> On 09/16/2014 10:15 AM, Pavel Stehule wrote: >>> >>> Why we don't introduce a temporary functions instead? >>> You can already do that

Re: [HACKERS] LIMIT for UPDATE and DELETE

(2014/08/15 6:18), Rukh Meski wrote: Based on the feedback on my previous patch, I've separated only the LIMIT part into its own feature. This version plays nicely with inheritance. The intended use is splitting up big UPDATEs and DELETEs into batches more easily and efficiently. IIUC, the pa

Re: [HACKERS] Anonymous code block with parameters

2014-09-16 10:01 GMT+02:00 Hannu Krosing : > On 09/16/2014 09:44 AM, Pavel Stehule wrote: > > > > 2014-09-16 9:24 GMT+02:00 Heikki Linnakangas : > >> On 09/16/2014 10:15 AM, Pavel Stehule wrote: >> >>> 2014-09-16 9:10 GMT+02:00 Heikki Linnakangas : >>> >>> On 09/16/2014 09:38 AM, Kalyanov Dmit

Re: [HACKERS] Anonymous code block with parameters

On 09/16/2014 10:57 AM, Craig Ringer wrote: On 09/16/2014 03:15 PM, Pavel Stehule wrote: Why we don't introduce a temporary functions instead? I think that'd be a lot cleaner and simpler. It's something I've frequently wanted, and as Hekki points out it's already possible by creating the func

Re: [HACKERS] Collation-aware comparisons in GIN opclasses

> > Changing the default opclasses should work if we make > > pg_dump --binary-upgrade dump the default opclasses with indexes > > and exclusion constraints. I think it makes sense to do so in > > --binary-upgrade mode. I can try to come with a patch for this. > > Can you explain it a bit more d

Re: [HACKERS] Anonymous code block with parameters

2014-09-16 10:09 GMT+02:00 Heikki Linnakangas : > On 09/16/2014 10:57 AM, Craig Ringer wrote: > >> On 09/16/2014 03:15 PM, Pavel Stehule wrote: >> >> Why we don't introduce a temporary functions instead? >>> >> >> I think that'd be a lot cleaner and simpler. It's something I've >> frequently want

Re: [HACKERS] Anonymous code block with parameters

Hi, On 2014-09-16 10:24:52 +0300, Heikki Linnakangas wrote: > On 09/16/2014 10:15 AM, Pavel Stehule wrote: > >Why we don't introduce a temporary functions instead? > > You can already do that: > > create function pg_temp.tempfunc(i int4) returns int4 as $$ begin end; $$ > language plpgsql; It's

Re: CRC algorithm (was Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes)

On Sat, Sep 13, 2014 at 1:33 AM, Heikki Linnakangas wrote: > On 09/12/2014 10:54 PM, Abhijit Menon-Sen wrote: >> At 2014-09-12 22:38:01 +0300, hlinnakan...@vmware.com wrote: >>> We probably should consider switching to a faster CRC algorithm again, >>> regardless of what we do with compression. >>

Re: [HACKERS] Patch to support SEMI and ANTI join removal

On Sat, Sep 13, 2014 at 1:38 AM, Tom Lane wrote: > David Rowley writes: > > On Fri, Sep 12, 2014 at 3:35 AM, Robert Haas > wrote: > >> I haven't read the patch, but I think the question is why this needs > >> to be different than what we do for left join removal. > > > I discovered over here ->

Re: [HACKERS] WAL format and API changes (9.5)

On 2014-09-15 15:41:22 +0300, Heikki Linnakangas wrote: > Here we go. I've split this again into two patches. The first patch is just > refactoring the current code. It moves XLogInsert into a new file, > xloginsert.c, and the definition of XLogRecord to new xlogrecord.h header > file. As a result,

Re: CRC algorithm (was Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes)

On 2014-09-16 15:43:06 +0530, Amit Kapila wrote: > On Sat, Sep 13, 2014 at 1:33 AM, Heikki Linnakangas > wrote: > > On 09/12/2014 10:54 PM, Abhijit Menon-Sen wrote: > >> At 2014-09-12 22:38:01 +0300, hlinnakan...@vmware.com wrote: > >>> We probably should consider switching to a faster CRC algorit

Re: CRC algorithm (was Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes)

On 09/16/2014 01:28 PM, Andres Freund wrote: On 2014-09-16 15:43:06 +0530, Amit Kapila wrote: On Sat, Sep 13, 2014 at 1:33 AM, Heikki Linnakangas wrote: On 09/12/2014 10:54 PM, Abhijit Menon-Sen wrote: At 2014-09-12 22:38:01 +0300, hlinnakan...@vmware.com wrote: We probably should consider s

Re: CRC algorithm (was Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes)

On 2014-09-16 13:49:20 +0300, Heikki Linnakangas wrote: > I used http://create.stephan-brumme.com/crc32/#slicing-by-8-overview as > reference - you can probably see the similarity. Any implementation is going > to look more or less the same, though; there aren't that many ways to write > the implem

[HACKERS] Minor improvement in lock.sgml

Here is a patch to a bit improve the reference page for the LOCK command. I think it'd be better for the isolation level to be in capitals and wrapped in the tags. Thanks, Best regards, Etsuro Fujita diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml index 26e424b..913afe7 100

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

> On Mon, Sep 15, 2014 at 8:38 AM, Kouhei Kaigai wrote: > >> > The only reason why I put separate hooks here is, > >> > create_custom_scan() needs to know exact size of the CustomScan > >> > node (including private fields), however, it is helpful for > >> > extensions to kick its callback to initi

Re: [HACKERS] WAL format and API changes (9.5)

On Mon, Sep 15, 2014 at 9:16 PM, Michael Paquier wrote: > 2) XLogCheckBufferNeedsBackup is not used. It can be removed. Please ignore this comment, XLogCheckBufferNeedsBackup is used in heapam.c. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Sequence Access Method WIP

On 2014-09-15 01:38:52 +0200, Petr Jelinek wrote: > - int64 minv, maxv, incby, bool is_cycled - these are basically options > giving info about how the new numbers are allocated (I guess some > implementations are not going to support all of those) > - bool is_called - the current built-in sequence

Re: [HACKERS] Scaling shared buffer eviction

On Sun, Sep 14, 2014 at 12:23 PM, Amit Kapila wrote: > On Fri, Sep 12, 2014 at 11:55 AM, Amit Chapel > wrote: > > On Thu, Sep 11, 2014 at 4:31 PM, Andres Freund > wrote: > > > On 2014-09-10 12:17:34 +0530, Amit Kapila wrote: > > I will post the data with the latest patch separately (where I wil

Re: CRC algorithm (was Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes)

On Tue, Sep 16, 2014 at 4:27 PM, Andres Freund wrote: > On 2014-09-16 13:49:20 +0300, Heikki Linnakangas wrote: > > I used http://create.stephan-brumme.com/crc32/#slicing-by-8-overview as > > reference - you can probably see the similarity. Any implementation is going > > to look more or less the

Re: [HACKERS] Triggers with DO functionality

On 17 February 2012 22:42, Jaime Casanova wrote: > On Fri, Feb 17, 2012 at 4:46 PM, Tom Lane wrote: > > > > Has anybody stopped to look at the SQL standard for this? In-line > > trigger definitions are actually what they intend, IIRC. > > > > this is what i found there > > ::= > CREATE TRIGG

Re: [HACKERS] Support for N synchronous standby servers

On Mon, Sep 15, 2014 at 3:00 PM, Michael Paquier wrote: > At least a set of hooks has the merit to say: do what you like with > your synchronous node policy. Sure. I dunno if people will find that terribly user-friendly, so we might not want that to be the ONLY thing we offer. But even if it is

Re: [HACKERS] Triggers with DO functionality

On 2014-09-16 13:15:59 +0100, Thom Brown wrote: > On 17 February 2012 22:42, Jaime Casanova wrote: > > > On Fri, Feb 17, 2012 at 4:46 PM, Tom Lane wrote: > > > > > > Has anybody stopped to look at the SQL standard for this? In-line > > > trigger definitions are actually what they intend, IIRC.

Re: [HACKERS] Triggers with DO functionality

On 16 September 2014 13:29, Andres Freund wrote: > On 2014-09-16 13:15:59 +0100, Thom Brown wrote: > > On 17 February 2012 22:42, Jaime Casanova wrote: > > > > > On Fri, Feb 17, 2012 at 4:46 PM, Tom Lane wrote: > > > > > > > > Has anybody stopped to look at the SQL standard for this? In-line >

Re: [HACKERS] Triggers with DO functionality

On 2014-09-16 13:42:22 +0100, Thom Brown wrote: > > > The function can't be the target of CREATE OR REPLACE FUNCTION. > > > > That *really* sucks. To the point of making the feature useless in my > > eyes. That's really something frequently done. > > > > Why not CREATE OR REPLACE TRIGGER? Wouldn'

Re: [HACKERS] Triggers with DO functionality

On 16 September 2014 13:45, Andres Freund wrote: > On 2014-09-16 13:42:22 +0100, Thom Brown wrote: > > > > The function can't be the target of CREATE OR REPLACE FUNCTION. > > > > > > That *really* sucks. To the point of making the feature useless in my > > > eyes. That's really something frequent

Re: [HACKERS] Triggers with DO functionality

On 2014-09-16 13:54:49 +0100, Thom Brown wrote: > On 16 September 2014 13:45, Andres Freund wrote: > > On 2014-09-16 13:42:22 +0100, Thom Brown wrote: > > > > > The function can't be the target of CREATE OR REPLACE FUNCTION. > > > > > > > > That *really* sucks. To the point of making the feature u

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

On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan wrote: > On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus wrote: >> Actually, having the keys all at the same level *is* relevant for the >> issue we're discussing. If those 270 keys are organized in a tree, it's >> not the same as having them all on

Re: [HACKERS] Collation-aware comparisons in GIN opclasses

On Tue, Sep 16, 2014 at 12:14 PM, Emre Hasegeli wrote: > > > Changing the default opclasses should work if we make > > > pg_dump --binary-upgrade dump the default opclasses with indexes > > > and exclusion constraints. I think it makes sense to do so in > > > --binary-upgrade mode. I can try to

Re: [HACKERS] LIMIT for UPDATE and DELETE

Etsuro Fujita wrote: > (2014/08/15 6:18), Rukh Meski wrote: >> Based on the feedback on my previous patch, I've separated only the >> LIMIT part into its own feature. This version plays nicely with >> inheritance. The intended use is splitting up big UPDATEs and DELETEs >> into batches more eas

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

On 09/16/2014 06:31 AM, Robert Haas wrote: > On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan wrote: >> On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus wrote: >>> Actually, having the keys all at the same level *is* relevant for the >>> issue we're discussing. If those 270 keys are organized in a t

Re: [HACKERS] Scaling shared buffer eviction

On Tue, Sep 16, 2014 at 8:18 AM, Amit Kapila wrote: > In most cases performance with patch is slightly less as compare > to HEAD and the difference is generally less than 1% and in a case > or 2 close to 2%. I think the main reason for slight difference is that > when the size of shared buffers i

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

On Tue, Sep 16, 2014 at 12:47 PM, Josh Berkus wrote: > On 09/16/2014 06:31 AM, Robert Haas wrote: >> On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan wrote: >>> On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus wrote: Actually, having the keys all at the same level *is* relevant for the iss

Re: [HACKERS] LIMIT for UPDATE and DELETE

On Tue, Sep 16, 2014 at 11:31 AM, Kevin Grittner wrote: > Etsuro Fujita wrote: >> (2014/08/15 6:18), Rukh Meski wrote: >>> Based on the feedback on my previous patch, I've separated only the >>> LIMIT part into its own feature. This version plays nicely with >>> inheritance. The intended use is

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

On 09/16/2014 09:54 AM, Robert Haas wrote: > On Tue, Sep 16, 2014 at 12:47 PM, Josh Berkus wrote: >> On 09/16/2014 06:31 AM, Robert Haas wrote: >>> On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan wrote: On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus wrote: > Actually, having the keys all

Re: [HACKERS] Selectivity estimation for inet operators

> > New version with semi join estimation function attached. > I have performed the following initial review: - Patch format. -- submitted as unified, but not sure it makes it any easier to read than context format. - Apply to current master (77e65bf). -- success (though, I do get "Stripping tra

Re: [HACKERS] jsonb contains behaviour weirdness

On 09/15/2014 11:12 AM, Tom Lane wrote: >> Or are you proposing that JSONARRAY @> JSONARRAY should work differently >> from ARRAY @> ARRAY? > > And no. It's a bug that jsonb array containment works differently from > regular array containment. We understand the source of the bug, ie a > mistaken

Re: [HACKERS] replicating DROP commands across servers

> > > I think there's been some changes to this patch since july, care to > > resend a new version? > > Sure, here it is. > > The only difference with the previous version is that it now also > supports column defaults. This was found to be a problem when you drop > a sequence that some column def

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

On 09/16/2014 07:47 PM, Josh Berkus wrote: On 09/16/2014 06:31 AM, Robert Haas wrote: On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan wrote: On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus wrote: Actually, having the keys all at the same level *is* relevant for the issue we're discussing. If

[HACKERS] Need guidance to startup

Hello everyone..i am new to PostgreSQL project. I had prior experience with sql+ , with oracle 11g database server. Kindly help me grasp more about the project or direct me in the right direction. Thank you, Tapan Halani

Re: [HACKERS] Support for N synchronous standby servers

On Tue, Sep 16, 2014 at 5:25 AM, Robert Haas wrote: > On Mon, Sep 15, 2014 at 3:00 PM, Michael Paquier > wrote: >> At least a set of hooks has the merit to say: do what you like with >> your synchronous node policy. > > Sure. I dunno if people will find that terribly user-friendly, so we > might

[HACKERS] Collations and Replication; Next Steps

Hello, Last month, I brought up the following issue to the general mailing list about how running streaming replication between machines running different versions of glibc can cause corrupt indexes. http://www.postgresql.org/message-id/ba6132ed-1f6b-4a0b-ac22-81278f5ab...@tripadvisor.com In th

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

On Tue, Sep 16, 2014 at 3:12 PM, Heikki Linnakangas wrote: > I'll leave it up to the jury to decide if we care or not. It seems like a > fairly unusual use case, where you push around large enough arrays or > objects to notice. Then again, I'm sure *someone* will do it. People do > strange things,

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

On Tue, Sep 16, 2014 at 1:11 PM, Josh Berkus wrote: >>> Well, I can only judge from the use cases I personally have, none of >>> which involve more than 100 keys at any level for most rows. So far >>> I've seen some people argue hypotetical use cases involving hundreds of >>> keys per level, but

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

Heikki, Robert: On 09/16/2014 11:12 AM, Heikki Linnakangas wrote: > Are you looking for someone with a real life scenario, or just synthetic > test case? The latter is easy to do. > > See attached test program. It's basically the same I posted earlier. > Here are the results from my laptop with T

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

On Tue, Sep 16, 2014 at 3:24 PM, Josh Berkus wrote: > Do you feel that way *as a code maintainer*? That is, if you ended up > maintaining the JSONB code, would you still feel that it's worth the > extra complexity? Because that will be the main cost here. I feel that Heikki doesn't have a reput

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

On 16/09/14 21:20, Robert Haas wrote: In practice, I'm not very surprised that the impact doesn't seem too bad when you're running SQL queries from the client. There's so much other overhead, for de-TOASTing and client communication and even just planner and executor costs, that this gets lost i

[HACKERS] New to PostGre SQL asking about write-ahead-log (WAL)

Hi, I am new to PostGre SQL and want to ask some questions. In my database class, we plan to work on a class project based on WAL. Since we are not familiar with WAL, we don't know what's a good start point. Could anyone point me to any documentation mentioning about WAL in PostGre SQL? It will be

[HACKERS] printing table in asciidoc with psql

Hi, I've been working a little bit on a patch for printing tables in asciidoc with psql. It's not finished yet, I'm not sure it there is any sense in supporting border types etc. The code is not cleared so far, but any remarks on the style not playing well with the normal postgres style of code ar

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

On 09/16/2014 10:37 PM, Robert Haas wrote: On Tue, Sep 16, 2014 at 3:24 PM, Josh Berkus wrote: Do you feel that way *as a code maintainer*? That is, if you ended up maintaining the JSONB code, would you still feel that it's worth the extra complexity? Because that will be the main cost here.

Re: [HACKERS] New to PostGre SQL asking about write-ahead-log (WAL)

On 09/16/2014 10:50 PM, Mingzhe Li wrote: Hi, I am new to PostGre SQL and want to ask some questions. In my database class, we plan to work on a class project based on WAL. Since we are not familiar with WAL, we don't know what's a good start point. Could anyone point me to any documentation men

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

On Tue, Sep 16, 2014 at 4:20 PM, Robert Haas wrote: > On Tue, Sep 16, 2014 at 1:11 PM, Josh Berkus wrote: > >>> Well, I can only judge from the use cases I personally have, none of > >>> which involve more than 100 keys at any level for most rows. So far > >>> I've seen some people argue hypote

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

On Mon, Sep 15, 2014 at 7:21 PM, Peter Geoghegan wrote: > On Mon, Sep 15, 2014 at 11:25 AM, Peter Geoghegan wrote: >> OK, I'll draft a patch for that today, including similar alterations >> to varstr_cmp() for the benefit of Windows and so on. > > I attach a much simpler patch, that only adds an

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

On Tue, Sep 16, 2014 at 1:45 PM, Robert Haas wrote: > Even though our testing seems to indicate that the memcmp() is > basically free, I think it would be good to make the effort to avoid > doing memcmp() and then strcoll() and then strncmp(). Seems like it > shouldn't be too hard. Really? The t

Re: [HACKERS] Sequence Access Method WIP

On 16/09/14 14:17, Andres Freund wrote: On 2014-09-15 01:38:52 +0200, Petr Jelinek wrote: There is also more needed than this, you need: - int64 value - first value allocated (value to be returned) - int64 nvalues - number of values allocated - int64 last - last cached value (used for cached/la

Re: [HACKERS] Collations and Replication; Next Steps

On 9/16/14 12:06 PM, Matthew Kelly wrote: > The second and far more challenging problem is how do we fix this issue? > As of our last discussion, Peter Geoghegan revived the proposal of > using ICU as an alternative. > > (http://www.postgresql.org/message-id/CAEYLb_WvdCzuL=cyf1xyzjwn-1cvo6kzeawm

Re: [HACKERS] PL/pgSQL 2

On 04/09/14 18:02, Craig Ringer wrote: On 09/04/2014 06:48 AM, Joshua D. Drake wrote: On 09/03/2014 11:48 AM, Robert Haas wrote: Anyway, to get back around to the topic of PL/SQL compatibility specifically, if you care about that issue, pick one thing that exists in PL/SQL but not in PL/pgsql

Re: [HACKERS] PL/pgSQL 2

On 03/09/14 20:48, Robert Haas wrote: On Tue, Sep 2, 2014 at 5: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 postgr

Re: [HACKERS] Collations and Replication; Next Steps

On Tue, Sep 16, 2014 at 2:07 PM, Peter Eisentraut wrote: > Clearly, this is worth documenting, but I don't think we can completely > prevent the problem. There has been talk of a built-in index integrity > checking tool. That would be quite useful. We could at least use the GNU facility for ver

Re: [HACKERS] Collations and Replication; Next Steps

On Tue, Sep 16, 2014 at 2:07 PM, Peter Eisentraut wrote: > It seems to me that this is a more general problem that can affect any > data type that relies on anything external. For example, you could > probably create a case where indexes are corrupted if you have two > different time zone databas

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

- Цитат от Robert Haas (robertmh...@gmail.com), на 16.09.2014 в 22:20 - > > In practice, I'm not very surprised that the impact doesn't seem too > bad when you're running SQL queries from the client. There's so much > other overhead, for de-TOASTing and client communication and even just

Re: [HACKERS] Need guidance to startup

On 09/17/2014 02:16 AM, Tapan Halani wrote: > Hello everyone..i am new to PostgreSQL project. I had prior experience > with sql+ , with oracle 11g database server. Kindly help me grasp more > about the project or direct me in the right direction. I've replied off-list to direct the poster to some

Re: [HACKERS] New to PostGre SQL asking about write-ahead-log (WAL)

On 09/17/2014 03:50 AM, Mingzhe Li wrote: > Hi, > > I am new to PostGre SQL and want to ask some questions. In my database > class, we plan to work on a class project based on WAL. Since we are not > familiar with WAL, we don't know what's a good start point. Could anyone > point me to any documen

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

Heikki Linnakangas writes: > On 09/16/2014 10:37 PM, Robert Haas wrote: >> On Tue, Sep 16, 2014 at 3:24 PM, Josh Berkus wrote: >>> Do you feel that way *as a code maintainer*? That is, if you ended up >>> maintaining the JSONB code, would you still feel that it's worth the >>> extra complexity?