Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote: > > Yes, the part-1 patch provides a set of interface portion to interact > > between the backend code and extension code. Rest of part-2 and part-3 > > portions are contrib modules that implements its feature on top of > > custom-scan API. > > Just

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

On 24 February 2014 16:01, Andres Freund wrote: > Hi, > > I took a quick peek at this, and noticed the following things: > * I am pretty sure this patch doesn't compile anymore after the latest > set of releases. Refreshed to v18, will post shortly. > * This definitely should include isolation

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote: > This regular one means usual tables. Even though custom implementation > may reference self-managed in-memory cache instead of raw heap, the table > pointed in user's query shall be a usual table. > In the past, Hanada-san had proposed an enhancement

Re: [HACKERS] jsonb and nested hstore

On Feb 25, 2014, at 1:57 PM, Hannu Krosing wrote: > It is not in any specs, but nevertheless all major imlementations do it and > some code depends on it. I have no doubt that some code depends on it, but "all major implementations" is too strong a statement. BSON, in particular, does not hav

Re: [HACKERS] jsonb and nested hstore

On 02/25/2014 08:54 PM, Josh Berkus wrote: > That's called a "straw man argument", Robert. > Me: We should recommend that people use jsonb unless they have a > specific reason for using json. We could also make the opposite argument - people use json unless they have a specific reason for using jso

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote: > > > Instead of custom node, it might be better idea to improve FDW > > > infrastructure to push join. For the starters, is it possible for > > > the custom scan node hooks to create a ForeignScan node? In general, > > > I think, it might be better f

Re: [HACKERS] jsonb and nested hstore

* Peter Geoghegan (p...@heroku.com) wrote: > On Tue, Feb 25, 2014 at 8:07 PM, Craig Ringer wrote: > > Please also highlight that any change will require a full table rewrite > > with an exclusive lock, so data type choices on larger tables may be > > hard to change later. > > It sure looks like t

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote: > Yes, the part-1 patch provides a set of interface portion to interact > between the backend code and extension code. Rest of part-2 and part-3 > portions are contrib modules that implements its feature on top of > custom-scan API. Just to come back t

Re: [HACKERS] jsonb and nested hstore

On Tue, Feb 25, 2014 at 8:07 PM, Craig Ringer wrote: > Please also highlight that any change will require a full table rewrite > with an exclusive lock, so data type choices on larger tables may be > hard to change later. It sure looks like they're binary-coercible to me: + CREATE CAST (hstore A

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote: > > Instead of custom node, it might be better idea to improve FDW > > infrastructure > > to push join. For the starters, is it possible for the custom scan node > > hooks to create a ForeignScan node? In general, I think, it might be better > > for th

Re: [HACKERS] jsonb and nested hstore

On 02/26/2014 06:21 AM, Merlin Moncure wrote: > On Tue, Feb 25, 2014 at 4:03 PM, Josh Berkus wrote: >> On 02/25/2014 12:12 PM, Robert Haas wrote: >>> I don't agree that jsonb should be preferred in all but a handful of >>> situations. Nor do I agree that partisanship belongs in our >>> documentat

Re: [HACKERS] Get more from indices.

Hello, At Tue, 25 Feb 2014 16:35:55 -0500, Robert Haas wrote > On Tue, Feb 25, 2014 at 3:36 AM, Kyotaro HORIGUCHI > wrote: > > May I mark this patch as "Ready for Committer" by myself since > > this was already marked so in last CF3 and have had no objection > > or new suggestion in this CF4 for

Re: contrib/cache_scan (Re: [HACKERS] What's needed for cache-only table scan?)

On Tue, Feb 25, 2014 at 11:13 AM, Haribabu Kommi wrote: > Thanks for the information, I will apply other patches also and start > testing. > When try to run the pgbench test, by default the cache-scan plan is not chosen because of more cost. So I increased the cpu_index_tuple_cost to a maximum va

Re: [HACKERS] inherit support for foreign tables

Hello, I tried minimal implementation to do that. At Tue, 25 Feb 2014 19:45:56 +0900, Etsuro Fujita wrote > In addition to an issue pointed out recently by Horiguchi-san, I've > found there is another issue we have to discuss. That is, we can't > build any parameterized Append paths for an inheri

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

Hi Kaigai-san, 2014-02-23 22:24 GMT+09:00 Kohei KaiGai : > (1) Interface to add alternative paths in addition to built-in join paths I found that create_custom_path is not used at all in your patch. I revised postgresql_fdw.c to use it like this. ... /* Create join information which is store

Re: [HACKERS] Minor performance improvement in transition to external sort

On Tue, Feb 25, 2014 at 2:55 PM, Jeremy Harris wrote: > On 24/02/14 17:38, Robert Haas wrote: >> >> On Thu, Feb 20, 2014 at 7:27 PM, Jeremy Harris wrote: >>> >>> Run under cachegrind, it takes about N/10 last-level cache misses, >>> all for the new item being introduced to the heap. The existing

Re: [HACKERS] In which good intentions are punished, take 2

On 02/25/2014 08:53 PM, Alvaro Herrera wrote: Tom Lane wrote: On the other hand, we evidently have got precious little other buildfarm coverage of the convert() family of functions, so maybe removing this test altogether wouldn't be the best thing either. We do have precious little testing on

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

Hi Kaigai-san, 2014-02-25 13:28 GMT+09:00 Kouhei Kaigai : > The reason why I asked the question above is, I haven't been 100% certain > about its usage. Indeed, semifactors is applied on a limited usage, but > quite easy to reproduce by extension later (using clauselist_selectivity) > if extension

Re: [HACKERS] In which good intentions are punished, take 2

Tom Lane wrote: > On the > other hand, we evidently have got precious little other buildfarm > coverage of the convert() family of functions, so maybe removing > this test altogether wouldn't be the best thing either. We do have precious little testing on encodings and conversions, yes. The probl

Re: [HACKERS] pg_dumpall reccomendation in release notes

On 02/25/2014 04:42 PM, Bruce Momjian wrote: > On Tue, Feb 25, 2014 at 06:41:26PM -0500, Tom Lane wrote: >> I'm not sure what "many limitations" you think pg_dumpall has that pg_dump >> doesn't. >> >> I do think that it might be time to reword this to recommend pg_upgrade >> first, though. ISTM th

Re: [HACKERS] extension_control_path

* Peter Eisentraut (pete...@gmx.net) wrote: > I'm massively in favor of this feature. (I had started writing it about > three times myself.) Agreed. > The problem I see, however, is that most extensions, by recommendation, > set module_pathname = '$libdir/pgfoo', and so relocating the control >

Re: [HACKERS] pg_dumpall reccomendation in release notes

On Tue, Feb 25, 2014 at 06:41:26PM -0500, Tom Lane wrote: > I'm not sure what "many limitations" you think pg_dumpall has that pg_dump > doesn't. > > I do think that it might be time to reword this to recommend pg_upgrade > first, though. ISTM that the current wording dates from when pg_upgrade >

[HACKERS] In which good intentions are punished, take 2

Since I committed 49c817eab78c6f0ce8c3bf46766b73d6cf3190b7 to make pg_do_encoding_conversion not fail silently, buildfarm member magpie has been whining: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=magpie&dt=2014-02-25%2011%3A00%3A08 To wit, that if you run contrib/citext's regression t

Re: [HACKERS] Bit data type header reduction in some cases

On Tue, Feb 25, 2014 at 09:32:55AM -0500, Tom Lane wrote: > Heikki Linnakangas writes: > > On 02/25/2014 08:23 AM, Haribabu Kommi wrote: > >> It's regarding a Todo item of "Bit data type header reduction" in some > >> cases. The header contains two parts. 1) The varlena header is > >> automatical

Re: [HACKERS] pg_dumpall reccomendation in release notes

On 02/25/2014 03:59 PM, Tom Lane wrote: > If we had a page discussing the pros and cons of different upgrade > methods, yeah, I'd be in favor of reducing the release-note text to a > pointer to that page. I don't see such a page in a quick skim of the > fine manual's table of contents though? I o

Re: [HACKERS] pg_dumpall reccomendation in release notes

Josh Berkus writes: > On 02/25/2014 03:41 PM, Tom Lane wrote: >> There's a very good reason for not recommending pg_dump in this context: >> it won't dump everything. Yeah, if you know what you're doing, you might >> use per-database pg_dump runs plus pg_dumpall -g to catch the roles etc, >> but

Re: [HACKERS] pg_dumpall reccomendation in release notes

On 02/25/2014 03:41 PM, Tom Lane wrote: > Josh Berkus writes: >> Can we change this text in the template release notes? > >> A dump/restore using >> pg_dumpall, >> or use of >> pg_upgrade

Re: [HACKERS] pg_dumpall reccomendation in release notes

Josh Berkus writes: > Can we change this text in the template release notes? > A dump/restore using > pg_dumpall, > or use of > pg_upgrade, is > required for those wishing to m

Re: [HACKERS] Ctrl+C from sh can shut down daemonized PostgreSQL cluster

Kevin Grittner writes: > Tom Lane wrote: >> Or we could wait to see if anybody reports this sort of behavior >> in a shell that won't be out of support before 9.4 gets out the >> door. > We have a field report of this happening in the sh shell in Solaris > 10.  Our staff has confirmed this.  In

[HACKERS] pg_dumpall reccomendation in release notes

Bruce, Tom: Can we change this text in the template release notes? A dump/restore using pg_dumpall, or use of pg_upgrade, is required for those wishing to migrate data from an

Re: [HACKERS] jsonb and nested hstore

On Tue, Feb 25, 2014 at 4:03 PM, Josh Berkus wrote: > On 02/25/2014 12:12 PM, Robert Haas wrote: >> I don't agree that jsonb should be preferred in all but a handful of >> situations. Nor do I agree that partisanship belongs in our >> documentation. Therefore, -1 for your proposal to recommend t

Re: [HACKERS] extension_control_path

I'm massively in favor of this feature. (I had started writing it about three times myself.) The problem I see, however, is that most extensions, by recommendation, set module_pathname = '$libdir/pgfoo', and so relocating the control files will still end up pointing to a not relocated library fil

Re: [HACKERS] jsonb and nested hstore

On 02/25/2014 12:12 PM, Robert Haas wrote: > I don't agree that jsonb should be preferred in all but a handful of > situations. Nor do I agree that partisanship belongs in our > documentation. Therefore, -1 for your proposal to recommend that, and > +1 for Merlin's proposal to present a compariso

Re: [HACKERS] Get more from indices.

On Tue, Feb 25, 2014 at 3:36 AM, Kyotaro HORIGUCHI wrote: > May I mark this patch as "Ready for Committer" by myself since > this was already marked so in last CF3 and have had no objection > or new suggestion in this CF4 for more than a month? Sounds fair. -- Robert Haas EnterpriseDB: http://w

Re: [HACKERS] Unfortunate choice of short switch name in pgbench

Robert Haas writes: > On Tue, Feb 25, 2014 at 2:49 PM, Tom Lane wrote: >> To fix this, I propose removing the -P short form and only allowing the >> long --progress form. I won't argue that this feature is completely >> useless, but for sure it's not something I'd want more often than once >> in

Re: [HACKERS] jsonb and nested hstore

Josh Berkus escribió: > (to clarify below: "json" refers to the current varlena datatype; JSON > refers to JSON serialized data). FWIW the term "varlena json" is misleading. jsonb is also varlena, only different. I think you need a different term to say that json uses the text representation.

Re: [HACKERS] [bug fix or improvement?] Correctly place DLLs for ECPG apps in bin folder

You should be able to do this without specifically referencing the names "libpq" or "ecpg". Look into the Makefile, if it defines SO_MAJOR_VERSION, then it's a library you are concerned with, and then do the copying or moving. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

On Mon, Feb 24, 2014 at 10:13 AM, Christian Kruse wrote: > To be honest, I don't like the idea of setting up this error context > only for log_lock_wait messages. This sounds unnecessary complex to me > and I think that in the few cases where this message doesn't add a > value (and thus is useless

Re: [HACKERS] define type_transform to new user defined type

Mohsen SM writes: > I want to create new type that is similar to varchar. > its size is variable. > I use CREATE TYPE query. > I define for that type this functions: > 1-typein > 2-typeoute > 3-typemodify_input > 4-typemodify_output > 5-type_transform > I can define 1 to 4 functions in CREATE TYP

Re: [HACKERS] install libpq.dll in bin directory on Windows / Cygwin

On 2/1/14, 3:22 PM, Andrew Dunstan wrote: > In the end I went with the way I had suggested, because that's what the > MSVC system does - it doesn't copy any other DLLs to the bin directory. > So doing that seemed sane for backpatching, to bring the two build > systems into sync. > > If you want to

Re: [HACKERS] Ctrl+C from sh can shut down daemonized PostgreSQL cluster

Tom Lane wrote: > Or we could wait to see if anybody reports this sort of behavior > in a shell that won't be out of support before 9.4 gets out the > door. We have a field report of this happening in the sh shell in Solaris 10.  Our staff has confirmed this.  In Solaris 10 they can start multip

Re: [HACKERS] [BUGS] BUG #9223: plperlu result memory leak

On Tue, Feb 25, 2014 at 6:56 AM, Sergey Burladyan wrote: > It looks like I found the problem, Perl use reference count and something that > is called "Mortal" for memory management. As I understand it, mortal is free > after FREETMPS. Plperl call FREETMPS in plperl_call_perl_func() but after it,

Re: [HACKERS] Dump pageinspect to 1.2: page_header with pg_lsn datatype

Robert Haas escribió: > On Mon, Feb 24, 2014 at 9:34 AM, Alvaro Herrera > wrote: > > Yeah, erroring out seems good enough. Particularly if you add a hint > > saying "please upgrade the extension". > > In past instances where this has come up, we have actually made the > .so backward-compatible.

Re: [HACKERS] Dump pageinspect to 1.2: page_header with pg_lsn datatype

On Mon, Feb 24, 2014 at 9:34 AM, Alvaro Herrera wrote: > Yeah, erroring out seems good enough. Particularly if you add a hint > saying "please upgrade the extension". In past instances where this has come up, we have actually made the .so backward-compatible. See pg_stat_statements in particula

[HACKERS] define type_transform to new user defined type

I want to create new type that is similar to varchar. its size is variable. I use CREATE TYPE query. I define for that type this functions: 1-typein 2-typeoute 3-typemodify_input 4-typemodify_output 5-type_transform I can define 1 to 4 functions in CREATE TYPE but I can't define type_transform for

Re: [HACKERS] jsonb and nested hstore

On Tue, Feb 25, 2014 at 1:54 PM, Josh Berkus wrote: > On 02/25/2014 10:50 AM, Robert Haas wrote: >> On Tue, Feb 25, 2014 at 1:45 PM, Josh Berkus wrote: >>> On 02/25/2014 10:31 AM, Robert Haas wrote: And I definitely don't agree that our documentation should push people towards stuffing

Re: [HACKERS] Unfortunate choice of short switch name in pgbench

On Tue, Feb 25, 2014 at 2:49 PM, Tom Lane wrote: > I just wasted some time puzzling over strange results from pgbench. > I eventually realized that I'd been testing against the wrong server, > because rather than "-p 65432" I'd typed "-P 65432", thereby invoking > the recently added --progress opt

Re: [HACKERS] Unfortunate choice of short switch name in pgbench

2014-02-25 20:49 GMT+01:00 Tom Lane : > I just wasted some time puzzling over strange results from pgbench. > I eventually realized that I'd been testing against the wrong server, > because rather than "-p 65432" I'd typed "-P 65432", thereby invoking > the recently added --progress option. pgben

Re: [HACKERS] Minor performance improvement in transition to external sort

On 24/02/14 17:38, Robert Haas wrote: On Thu, Feb 20, 2014 at 7:27 PM, Jeremy Harris wrote: Run under cachegrind, it takes about N/10 last-level cache misses, all for the new item being introduced to the heap. The existing code takes none at all. Can you explain this further? This seems lik

[HACKERS] Unfortunate choice of short switch name in pgbench

I just wasted some time puzzling over strange results from pgbench. I eventually realized that I'd been testing against the wrong server, because rather than "-p 65432" I'd typed "-P 65432", thereby invoking the recently added --progress option. pgbench has no way to know that that isn't what I me

Re: [HACKERS] Changeset Extraction v7.7

Hi, On 2014-02-25 13:47:49 -0500, Robert Haas wrote: > On Mon, Feb 24, 2014 at 6:16 PM, Andres Freund wrote: > > I actually thought they'd be too ugly to live and we'd remove them > > pre-commit. > > Might be getting to be about that time, then. I want to leave them in until the slot semantics

Re: [HACKERS] jsonb and nested hstore

On 02/25/2014 10:54 AM, Josh Berkus wrote: On 02/25/2014 10:50 AM, Robert Haas wrote: On Tue, Feb 25, 2014 at 1:45 PM, Josh Berkus wrote: On 02/25/2014 10:31 AM, Robert Haas wrote: And I definitely don't agree that our documentation should push people towards stuffing everything in a JSON blo

Re: [HACKERS] jsonb and nested hstore

On 02/25/2014 09:45 AM, Bruce Momjian wrote: >> It hurts our adoption substantially to confuse developers. We need to >> recommend one type over the other, hence "Use jsonb unless you need X". >> Merlin is pushing the type of multivariable comparison where *I* >> wouldn't be able to make sense of

Re: [HACKERS] jsonb and nested hstore

On 02/25/2014 10:50 AM, Robert Haas wrote: > On Tue, Feb 25, 2014 at 1:45 PM, Josh Berkus wrote: >> On 02/25/2014 10:31 AM, Robert Haas wrote: >>> And I definitely don't >>> agree that our documentation should push people towards stuffing >>> everything in a JSON blob instead of using real column

Re: [HACKERS] Minor comment improvements in tablecmds.c

On Tue, Feb 25, 2014 at 1:44 PM, Alvaro Herrera wrote: > Etsuro Fujita wrote: >> This is a small patch to improve comments in tablecmds.c. Please find >> attached a patch. > > I find both patched and unpatched to be pretty illegible. How about > something like > >> /* >> - * Execute ALTER TABLE

Re: [HACKERS] jsonb and nested hstore

On Tue, Feb 25, 2014 at 1:45 PM, Josh Berkus wrote: > On 02/25/2014 10:31 AM, Robert Haas wrote: >> And I definitely don't >> agree that our documentation should push people towards stuffing >> everything in a JSON blob instead of using real column definitions. > > > > Where did you get this

Re: [HACKERS] Changeset Extraction v7.7

On Mon, Feb 24, 2014 at 6:16 PM, Andres Freund wrote: > I actually thought they'd be too ugly to live and we'd remove them > pre-commit. Might be getting to be about that time, then. >> - if (nrels > 0 || nmsgs > 0 || RelcacheInitFileInval || >> forceSyncCommit) >> +

Re: [HACKERS] jsonb and nested hstore

On 02/25/2014 10:31 AM, Robert Haas wrote: > And I definitely don't > agree that our documentation should push people towards stuffing > everything in a JSON blob instead of using real column definitions. Where did you get this out of my doc patch? -- Josh Berkus PostgreSQL Experts Inc. ht

Re: [HACKERS] Minor comment improvements in tablecmds.c

Etsuro Fujita wrote: > This is a small patch to improve comments in tablecmds.c. Please find > attached a patch. I find both patched and unpatched to be pretty illegible. How about something like > /* > - * Execute ALTER TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE RENAME > + * Execute ALTER RENAM

Re: [HACKERS] Minor comment improvements in tablecmds.c

On Mon, Feb 24, 2014 at 9:40 PM, Etsuro Fujita wrote: > This is a small patch to improve comments in tablecmds.c. Please find > attached a patch. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] jsonb and nested hstore

On Tue, Feb 25, 2014 at 12:38 PM, Josh Berkus wrote: > On 02/25/2014 08:13 AM, Robert Haas wrote: >> I think you've got your head stuck deeply in the sand. The json data >> type works exactly like the xml data type has always worked. There >> have been occasional noises about making an xmlb data

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

On 2014-02-25 13:21:46 -0500, Tom Lane wrote: > Bruce Momjian writes: > > On Tue, Feb 25, 2014 at 12:18:02PM -0500, Peter Eisentraut wrote: > >> As I mentioned, I would just cut those introductory parts out. > > > Should we link to the Debian wiki content? > > -1. We generally don't link to our

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

Bruce Momjian writes: > On Tue, Feb 25, 2014 at 12:18:02PM -0500, Peter Eisentraut wrote: >> As I mentioned, I would just cut those introductory parts out. > Should we link to the Debian wiki content? -1. We generally don't link to our *own* wiki in our SGML docs, let alone things that aren't e

[HACKERS] Avoiding deeply nested AND/OR trees in the parser

Over in http://www.postgresql.org/message-id/bay176-w382a9de827ebc8e602b7bbc5...@phx.gbl there's a complaint about getting "stack depth limit exceeded" from a query of the form select count(*) from gui_die_summary where (x_coord, y_coord) in ((25,5),(41,13),(25,7),(28,3),(25,8),(34,7),(26,6),(21,1

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

On Tue, Feb 25, 2014 at 12:18:02PM -0500, Peter Eisentraut wrote: > On 2/25/14, 11:08 AM, Christian Kruse wrote: > > Hi, > > > > On 25/02/14 17:01, Andres Freund wrote: > >>> And if we did, we shouldn't copy it verbatim from the Debian wiki > >>> without attribution. > >> > >> Is it actually? A qu

Re: [HACKERS] jsonb and nested hstore

On Tue, Feb 25, 2014 at 09:38:50AM -0800, Josh Berkus wrote: > > In short, I think you're viewing everything about jsonb with > > rose-colored glasses on, and that your enthusiasm is mostly wishful > > thinking. Will there be good things about jsonb? Of course. Will > > lots of people want to us

Re: [HACKERS] jsonb and nested hstore

On 02/25/2014 08:13 AM, Robert Haas wrote: > I think you've got your head stuck deeply in the sand. The json data > type works exactly like the xml data type has always worked. There > have been occasional noises about making an xmlb data type, but > nobody's minded enough to do anything about it

Re: [HACKERS] Patch: show xid and xmin in pg_stat_activity and pg_stat_replication

On Mon, Feb 24, 2014 at 2:49 PM, Christian Kruse wrote: > attached you will find a fixed version. Committed, after fixing the regression test outputs. I also changed the new fields to be NULL rather than 0 when they are invalid, because that way applying age() to that column does something usefu

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

On 2/25/14, 11:08 AM, Christian Kruse wrote: > Hi, > > On 25/02/14 17:01, Andres Freund wrote: >>> And if we did, we shouldn't copy it verbatim from the Debian wiki >>> without attribution. >> >> Is it actually? A quick comparison doesn't show that many similarities? >> Christian? > > Not as far

Re: [HACKERS] varchar_transform

On Mon, Feb 24, 2014 at 2:11 AM, Mohsen SM wrote: > when did use varchar_transform function? > src/backend/uitls/adt/varchar.c. The main point of that machinery is that if you do something like ALTER TABLE zot ALTER COLUMN thunk SET DATA TYPE varchar(30) on a column that is currently varchar(20),

Re: [HACKERS] 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT ..

On Sat, Feb 22, 2014 at 7:02 PM, Rukh Meski wrote: > Sorry, I wanted to minimize the attention my message attracts. I mostly > posted it to let people know I plan on working on this for 9.5 to avoid > duplicated effort. I will post more documentation and my reasons for wanting > this feature

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

On Mon, Feb 24, 2014 at 1:05 PM, Bruce Momjian wrote: > On Mon, Feb 17, 2014 at 11:14:33AM -0500, Bruce Momjian wrote: >> On Sun, Feb 16, 2014 at 09:26:47PM -0500, Robert Haas wrote: >> > > So, would anyone like me to create patches for any of these items before >> > > we hit 9.4 beta? We have ad

Re: [HACKERS] walsender doesn't send keepalives when writes are pending

On Tue, Feb 25, 2014 at 11:23 AM, Andres Freund wrote: > On 2014-02-25 11:15:46 -0500, Robert Haas wrote: >> On Tue, Feb 25, 2014 at 10:54 AM, Andres Freund >> wrote: >> > I am not sure I can follow. Why doesn't it make sense to send out the >> > keepalive (with replyRequested = true) when we're

Re: [HACKERS] walsender doesn't send keepalives when writes are pending

On 2014-02-25 11:15:46 -0500, Robert Haas wrote: > On Tue, Feb 25, 2014 at 10:54 AM, Andres Freund > wrote: > > I am not sure I can follow. Why doesn't it make sense to send out the > > keepalive (with replyRequested = true) when we're busy sending stuff > > (which will be the case most of the ti

Re: [HACKERS] walsender doesn't send keepalives when writes are pending

On Tue, Feb 25, 2014 at 10:54 AM, Andres Freund wrote: > I am not sure I can follow. Why doesn't it make sense to send out the > keepalive (with replyRequested = true) when we're busy sending stuff > (which will be the case most of the time on a busy server)? It may very well make sense, but your

Re: [HACKERS] jsonb and nested hstore

On Mon, Feb 24, 2014 at 12:31 PM, Josh Berkus wrote: > Aside from that, I want our docs to make a strong endorsement of using > jsonb over json for most users. jsonb will continue to be developed and > improved in the future; it is very unlikely that json will. Maybe > that's what I should say r

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

Hi, On 25/02/14 17:01, Andres Freund wrote: > > And if we did, we shouldn't copy it verbatim from the Debian wiki > > without attribution. > > Is it actually? A quick comparison doesn't show that many similarities? > Christian? Not as far as I know. But of course, as I wrote the text I _also_ (t

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

Hi, On 25/02/14 10:29, Peter Eisentraut wrote: > I don't think we should be explaining the basics of OS memory management > in our documentation. Well, I'm confused. I thought that's exactly what has been asked. > And if we did, we shouldn't copy it verbatim from the Debian wiki > without attrib

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

On 2014-02-25 10:29:32 -0500, Peter Eisentraut wrote: > On 1/30/14, 2:28 AM, Christian Kruse wrote: > > after I finally got documentation compilation working I updated the > > patch to be syntactically correct. You will find it attached. > > I don't think we should be explaining the basics of OS m

Re: [HACKERS] walsender doesn't send keepalives when writes are pending

On Fri, Feb 14, 2014 at 7:05 AM, Andres Freund wrote: > In WalSndLoop() we do: > > wakeEvents = WL_LATCH_SET | WL_POSTMASTER_DEATH | WL_TIMEOUT | > WL_SOCKET_READABLE; > > if (pq_is_send_pending()) > wakeEvents |= WL_SOCKET_WRITEABLE; > else if (wal_sender_timeout > 0 &

Re: [HACKERS] walsender doesn't send keepalives when writes are pending

On 2014-02-25 10:45:55 -0500, Robert Haas wrote: > On Fri, Feb 14, 2014 at 7:05 AM, Andres Freund wrote: > > In WalSndLoop() we do: > > > > wakeEvents = WL_LATCH_SET | WL_POSTMASTER_DEATH | WL_TIMEOUT | > > WL_SOCKET_READABLE; > > > > if (pq_is_send_pending()) > > wakeEvent

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

On Tue, Feb 25, 2014 at 10:29 AM, Peter Eisentraut wrote: > And if we did, we shouldn't copy it verbatim from > the Debian wiki without attribution. That is seriously not cool. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hacker

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

On 1/30/14, 2:28 AM, Christian Kruse wrote: > after I finally got documentation compilation working I updated the > patch to be syntactically correct. You will find it attached. I don't think we should be explaining the basics of OS memory management in our documentation. And if we did, we should

Re: [HACKERS] often PREPARE can generate high load (and sometimes minutes long unavailability)

2014-02-25 11:29 GMT+01:00 Pavel Stehule : > Hello > > > 2014-02-24 21:31 GMT+01:00 Jeff Janes : > > On Mon, Feb 24, 2014 at 7:02 AM, Pavel Stehule wrote: >> >>> >>> >>> >>> 2014-02-23 21:32 GMT+01:00 Andres Freund : >>> >>> Hi, On 2014-02-23 20:04:39 +0100, Pavel Stehule wrote: > T

Re: [HACKERS] jsonb and nested hstore

On Mon, Feb 24, 2014 at 1:15 PM, Andrew Dunstan wrote: > On 02/24/2014 11:06 AM, Merlin Moncure wrote: >> >> On Mon, Feb 24, 2014 at 9:08 AM, Merlin Moncure >> wrote: >>> >>> On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure >>> wrote: I still find the phrasing "as jsonb is more efficien

Re: [HACKERS] [pgsql-advocacy] GSoC 2014 - mentors, students and admins

Awesome. I can be an assistant mentor for this one is possible or I could mentor some other project. On Tuesday, February 25, 2014, Andreas 'ads' Scherbaum < adsm...@wars-nicht.de> wrote: > > Hi, > > On 01/28/2014 06:46 PM, Atri Sharma wrote: > >> On Tue, Jan 28, 2014 at 11:04 PM, Thom Brown >

Re: [HACKERS] Bit data type header reduction in some cases

Heikki Linnakangas writes: > On 02/25/2014 08:23 AM, Haribabu Kommi wrote: >> It's regarding a Todo item of "Bit data type header reduction" in some >> cases. The header contains two parts. 1) The varlena header is >> automatically converted to 1 byte header from 4 bytes in case of small >> data.

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

2014-02-25 20:32 GMT+09:00 Ashutosh Bapat : > > On Tue, Feb 25, 2014 at 3:39 PM, Kouhei Kaigai wrote: >> >> > Sorry for jumping into this late. >> > >> > Instead of custom node, it might be better idea to improve FDW >> > infrastructure >> > to push join. For the starters, is it possible for the c

Re: [HACKERS] [BUGS] BUG #9223: plperlu result memory leak

Hello, All! eshkin...@gmail.com writes: > create function perl_test(IN data text, OUT v1 text, OUT v2 integer, OUT v3 > integer, OUT v4 json, OUT v5 json) > returns record as > $BODY$ > > use strict; > use warnings; > > my $res->{'v1'} = 'content'; > > return $res; > > $BODY$ > language plper

Re: [HACKERS] [pgsql-advocacy] GSoC 2014 - mentors, students and admins

Hi, On 01/28/2014 06:46 PM, Atri Sharma wrote: On Tue, Jan 28, 2014 at 11:04 PM, Thom Brown mailto:t...@linux.com>> wrote: Hi all, Application to Google Summer of Code 2014 can be made as of next Monday (3rd Feb), and then there will be a 12 day window in which to submit an ap

Re: [HACKERS] Same double precision operations, different results

Thx Tom!! Yep, I focused on all trigonometric functions take arguments and return values of type double precision. Looking for the error I lost focus on numeric values directly on the select and diff inner calculations. I think best approach will be maintain double precision on trigonometric calc

Re: [HACKERS] typemode for variable types

Also keep in mind that the system doesn't always retain the typmod. So the datum should be possible to interpret without the typmod. Incidental effects such as length limits or precision displayed are ok but the meaning shouldn't be changed. -- greg On 24 Feb 2014 20:34, "Tom Lane" wrote: > Al

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

On Feb24, 2014, at 17:50 , Dean Rasheed wrote: > On 20 February 2014 01:48, Florian Pflug wrote: >> On Jan29, 2014, at 13:45 , Florian Pflug wrote: >>> In fact, I'm >>> currently leaning towards just forbidding non-strict forward transition >>> function with strict inverses, and adding non-NULL

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

On Tue, Feb 25, 2014 at 3:39 PM, Kouhei Kaigai wrote: > > Sorry for jumping into this late. > > > > Instead of custom node, it might be better idea to improve FDW > infrastructure > > to push join. For the starters, is it possible for the custom scan node > > hooks to create a ForeignScan node? I

Re: [HACKERS] inherit support for foreign tables

In addition to an issue pointed out recently by Horiguchi-san, I've found there is another issue we have to discuss. That is, we can't build any parameterized Append paths for an inheritance tree that contains at least one foreign table, in set_append_rel_pathlist(). This is because the patch doe

Re: [HACKERS] often PREPARE can generate high load (and sometimes minutes long unavailability)

Hello 2014-02-24 21:31 GMT+01:00 Jeff Janes : > On Mon, Feb 24, 2014 at 7:02 AM, Pavel Stehule wrote: > >> >> >> >> 2014-02-23 21:32 GMT+01:00 Andres Freund : >> >> Hi, >>> >>> On 2014-02-23 20:04:39 +0100, Pavel Stehule wrote: >>> > There is relative few very long ProcArrayLocks lwlocks >>> > >

[HACKERS] [ISSUE] pg_dump: schema with OID 0 does not exist

Hi, Recently we observed below errors while taking dump after upgrading from 9.0.13 to 9.1.9. pg_dump: schema with OID 0 does not exist I referred similar issues reported previously ( http://www.postgresql.org/message-id/CAGWYGjXRJj=zugejv0ckvn4zf9hb92q+7e3aqfcvbgbmb9z...@mail.gmail.com) and get

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

> Sorry for jumping into this late. > > Instead of custom node, it might be better idea to improve FDW infrastructure > to push join. For the starters, is it possible for the custom scan node > hooks to create a ForeignScan node? In general, I think, it might be better > for the custom scan hooks

Re: [HACKERS] Dump pageinspect to 1.2: page_header with pg_lsn datatype

On 25 Feb 2014 08:54, "Heikki Linnakangas" wrote: > > > I hope there are no applications relying on pageinspect. It's a very low-level tool. Or if someone has written a nice GUI around it, I'd like to hear about it so that I can start using it :-). > > >> I see more flexibility to keep them as the

Re: [HACKERS] Trigger information for auto_explain.

Hi, I saw this patch has been moved into "committed patches" but only the first part (0001_..) for the core is committed as of 32001ab but the rest for extension side seem not to have been committed. Would you mind taking a look on that, Álvaro? regards, At Wed, 22 Jan 2014 17:28:27 +0900, Kyota

  1   2   >