Hi Peter,
thank you for your nice words, much appreciated. I'm sorry that I was
so whiny about this in the last post.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
pgpxVj8SJRDQS.pgp
Description: PGP sign
Hi,
On 26/02/14 13:13, Alvaro Herrera wrote:
>
> There's one thing that rubs me the wrong way about all this
> functionality, which is that we've named it "huge TLB pages". That is
> wrong -- the TLB pages are not huge. In fact, as far as I understand,
> the TLB doesn't have pages at all. It's
On 02/26/2014 07:41 PM, Josh Berkus wrote:
> On 02/26/2014 07:02 AM, Merlin Moncure wrote:
>> On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing wrote:
>>> It is not in any specs, but nevertheless all major imlementations do it and
>>> some code depends on it.
>>> IIRC, this behaviour is currently als
On Thu, Feb 27, 2014 at 8:51 AM, Tom Lane wrote:
> Noah Misch writes:
> > On Tue, Feb 25, 2014 at 01:15:09PM -0500, Tom Lane wrote:
> >> Really if we wanted to fix
> >> this issue we'd need to hack up transformAExprAnd/transformAExprOr so
> that
> >> they recognized nested ANDs/ORs and flattened
On Mon, Feb 03, 2014 at 07:36:22PM +0900, Kyotaro HORIGUCHI wrote:
> > > create table parent (a int, b int);
> > > create table child () inherits (parent);
> > > insert into parent values (1,10);
> > > insert into child values (2,20);
> > > select a, b from parent union all select a, b from child;
Hello,
> 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
* Andrew Dunstan (and...@dunslane.net) wrote:
> The jsonb set will get larger as time goes on. I don't think either
> of you are thinking very clearly about how we would do this.
> Extensions can't call each other's code.
Yeah, that was puzzling me too.
Agree with the rest of your comments as wel
On 02/26/2014 09:43 PM, Peter Geoghegan wrote:
On Wed, Feb 26, 2014 at 6:29 PM, Robert Haas wrote:
Why can't this whole thing be shipped as an extension? It might well
be more convenient to have the whole thing packaged as an extension
than to have parts of it in core and parts of it not in
Noah Misch writes:
> On Tue, Feb 25, 2014 at 01:15:09PM -0500, Tom Lane wrote:
>> Really if we wanted to fix
>> this issue we'd need to hack up transformAExprAnd/transformAExprOr so that
>> they recognized nested ANDs/ORs and flattened them on the spot. This
>> might not be a bad idea, but it's s
On Wed, Feb 26, 2014 at 6:29 PM, Robert Haas wrote:
> Why can't this whole thing be shipped as an extension? It might well
> be more convenient to have the whole thing packaged as an extension
> than to have parts of it in core and parts of it not in core.
That's a good question. I think having
On Wed, Feb 26, 2014 at 12:29 PM, Andres Freund wrote:
> On 2014-02-24 17:06:53 -0500, Robert Haas wrote:
>> - heap_page_prune_opt(scan->rs_rd, buffer, RecentGlobalXmin);
>> + if (IsSystemRelation(scan->rs_rd)
>> + || RelationIsAccessibleInLogicalDecoding(scan->rs_rd))
>>
On Wed, Feb 26, 2014 at 3:45 PM, Josh Berkus wrote:
> On 02/26/2014 11:39 AM, Merlin Moncure wrote:
>> On Wed, Feb 26, 2014 at 12:05 PM, Josh Berkus wrote:
>>> On 02/26/2014 09:57 AM, Merlin Moncure wrote:
What is not going to be so clear for users (particularly without good
supporting
On 02/26/2014 08:09 PM, Peter Geoghegan wrote:
On Wed, Feb 26, 2014 at 5:06 PM, Alvaro Herrera
wrote:
I think that this is not a great idea. I think that we should do away
with the GUC, but keep the function hstore_print() so we can pretty
print that way. I don't believe that this falls afoul
On Wed, Feb 26, 2014 at 5:06 PM, Alvaro Herrera
wrote:
>> I think that this is not a great idea. I think that we should do away
>> with the GUC, but keep the function hstore_print() so we can pretty
>> print that way. I don't believe that this falls afoul of the usual
>> obvious reasons for not va
Peter Geoghegan wrote:
> On Wed, Feb 26, 2014 at 2:10 PM, Andrew Dunstan wrote:
> > new patch attached, change pushed to github.
>
> > + /* GUC variables */
> > + static bool pretty_print_var = false;
> > + #define SET_PRETTY_PRINT_VAR(x) ((pretty_print_var) ? \
> > +
Andres Freund wrote:
> On 2014-02-26 16:23:12 -0500, Andrew Dunstan wrote:
> > >>+ if (va->string.len == vb->string.len)
> > >>+ {
> > >>+ res = memcmp(va->string.val, vb->string.val, va->string.len);
> > >>+ if (res == 0 && arg)
> > >>+ *(bool *) arg = true;
> > >S
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > I (plan to) use custom-scan of course. Once a relation is referenced
> > and optimizer decided GPU acceleration is cheaper, associated custom-
> > scan node read the data from underlying relation (or in-memory cache
> > if exists) then move to the
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > IIUC, his approach was integration of join-pushdown within FDW APIs,
> > however, it does not mean the idea of remote-join is rejected.
>
> For my part, trying to consider doing remote joins *without* going through
> FDWs is just nonsensical. Wh
On Wed, Feb 26, 2014 at 2:10 PM, Andrew Dunstan wrote:
> new patch attached, change pushed to github.
> + /* GUC variables */
> + static bool pretty_print_var = false;
> + #define SET_PRETTY_PRINT_VAR(x) ((pretty_print_var) ? \
> +
On 02/26/2014 05:48 PM, Erik Rijkers wrote:
On Wed, February 26, 2014 23:10, Andrew Dunstan wrote:
new patch attached, change pushed to github.
[jsonb-13.patch.gz]
This does not apply, see attached: src/backend/utils/adt/jsonfuncs.c.rej
Please ignore if this was not supposed to work togethe
On Tue, Feb 25, 2014 at 01:15:09PM -0500, Tom Lane wrote:
> 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
Hello Josh,
>This would break at least 4 major applications which I personally have
I clearly see this issue, and in my opinion , this is the greatest challenge
for this proposal. So, I will say -1 if I consider the re-factoring need to be
done in old code. My main concern of this post is not
On Wed, February 26, 2014 23:10, Andrew Dunstan wrote:
>
> new patch attached, change pushed to github.
>
> [jsonb-13.patch.gz]
>
This does not apply, see attached: src/backend/utils/adt/jsonfuncs.c.rej
Please ignore if this was not supposed to work together with the earlier
nested-hstore-11.pat
On 2014-02-26 16:23:12 -0500, Andrew Dunstan wrote:
> On 02/10/2014 09:11 PM, Andres Freund wrote:
> >Is it just me or is jsonapi.h not very well documented?
>
>
> What about it do you think is missing? In any case, it's hardly relevant to
> this patch, so I'll take that as obiter dicta.
It's r
On 2014-02-26 18:18:05 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > static void
> > heap_xlog_lock(XLogRecPtr lsn, XLogRecord *record)
> > {
> > ...
> > HeapTupleHeaderClearHotUpdated(htup);
> > HeapTupleHeaderSetXmax(htup, xlrec->locking_xid);
> > HeapTupleHeaderSetCmax(h
On 2014-02-26 19:03:42 -0300, Alvaro Herrera wrote:
> I forgot to mention that the bug can be reproduced in a hot-standby
> setup with the attached isolation spec. Note that full_page_writes must
> be turned off (otherwise, the updates use full-page writes and then the
> bogus code is not run). O
On 02/26/2014 04:59 PM, Peter Geoghegan wrote:
On Wed, Feb 26, 2014 at 1:23 PM, Andrew Dunstan wrote:
+ if (va->string.len == vb->string.len)
+ {
+ res = memcmp(va->string.val, vb->string.val,
va->string.len);
+ if (res == 0 && arg)
+
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> >> Who do you think should have a say about where to load the dynamic
> >> librairies from? hackers, packagers, system admins, dbas or users?
> >
> > My gut feeling
I forgot to mention that the bug can be reproduced in a hot-standby
setup with the attached isolation spec. Note that full_page_writes must
be turned off (otherwise, the updates use full-page writes and then the
bogus code is not run). Once the spec is executed, in the replica run
SET enable_seq
On Wed, Feb 26, 2014 at 1:23 PM, Andrew Dunstan wrote:
>>> + if (va->string.len == vb->string.len)
>>> + {
>>> + res = memcmp(va->string.val, vb->string.val,
>>> va->string.len);
>>> + if (res == 0 && arg)
>>> + *(bool *) arg = true;
>>
Stephen Frost writes:
> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
>> Who do you think should have a say about where to load the dynamic
>> librairies from? hackers, packagers, system admins, dbas or users?
>
> My gut feeling on this is packages and sysadmins. Do you see it
+1
>> Who d
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Who do you think should have a say about where to load the dynamic
> librairies from? hackers, packagers, system admins, dbas or users?
My gut feeling on this is packages and sysadmins. Do you see it
differently? I generally *don't* think DBA
Stephen Frost writes:
> I find this role reversal to be quite bizarre.
Who do you think should have a say about where to load the dynamic
librairies from? hackers, packagers, system admins, dbas or users?
Who do you think is currently editing the setup that decides where to
load the dynamic lib
On Thu, Feb 27, 2014 at 1:07 AM, Alexander Korotkov wrote:
> On Thu, Feb 20, 2014 at 1:48 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> On 02/09/2014 12:11 PM, Alexander Korotkov wrote:
>>
>>> I've rebased catalog changes with last master. Patch is attached. I've
>>> rerun my tes
Andres Freund wrote:
> static void
> heap_xlog_lock(XLogRecPtr lsn, XLogRecord *record)
> {
> ...
> HeapTupleHeaderClearHotUpdated(htup);
> HeapTupleHeaderSetXmax(htup, xlrec->locking_xid);
> HeapTupleHeaderSetCmax(htup, FirstCommandId, false);
> /* Make sure there is no forward ch
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> I don't see any confusion about dynamic library name resolving added
> from the extension_control_path, I'm sorry. Simply because I don't
> expect people to use the facility without a third party software
> designed to fill-in the gap.
>
> You'r
Stephen Frost writes:
> I didn't suggest anywhere that the proposed patch changed the rules at
> all- instead I was trying to point out that by adding this functionality
> and *not* changing the way that lookup is done *is going to cause
> confusion*.
I don't see any confusion about dynamic libra
On Thu, Feb 20, 2014 at 1:48 PM, Heikki Linnakangas wrote:
> On 02/09/2014 12:11 PM, Alexander Korotkov wrote:
>
>> I've rebased catalog changes with last master. Patch is attached. I've
>> rerun my test suite with both last master ('committed') and attached
>> patch ('ternary-consistent').
>>
>
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> The rules that PostgreSQL follows to know where to load the library from
> are not changed *at all* by this patch. In my book, it makes the whole
> topic irrelevant to the review.
I'm really quite tired of the constant dismissal of anything brou
Stephen Frost writes:
> This is true and Debian puts the control/sql files into a different
> directory than the .so files, of course. Still, the issue here is how
> we find the .so files- the user *has* to tell us where the control file
> is, if it isn't in the default location, and the assumpti
On 02/26/2014 11:39 AM, Merlin Moncure wrote:
> On Wed, Feb 26, 2014 at 12:05 PM, Josh Berkus wrote:
>> On 02/26/2014 09:57 AM, Merlin Moncure wrote:
>>> What is not going to be so clear for users (particularly without good
>>> supporting documentation) is how things break down in terms of usage
>
2014-02-26 21:12 GMT+01:00 AlexK :
> It would be nice to be able to declare something like this for a function
> returning an unnested array:
>
> RETURNS TABLE(some_value mytable.myarray_column%ELEMENT_TYPE, ...)
>
it has sense, but it is dangerous with current implementation. There are no
persis
It would be nice to be able to declare something like this for a function
returning an unnested array:
RETURNS TABLE(some_value mytable.myarray_column%ELEMENT_TYPE, ...)
Does it make sense?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Adding-a-copying-type-for-arr
Andres Freund escribió:
> On 2014-02-26 15:30:55 -0300, Alvaro Herrera wrote:
> > Andres Freund escribió:
> >
> > > I am wondering about the related situation of GetOldestXmin()
> > > callers. There's a fair bit of duplicated logic in the callers, before
> > > but especially after this patchset. W
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Peter Eisentraut writes:
> > 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 libra
On 26/02/14 03:08, Robert Haas wrote:
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 t
Leon Smith wrote
> Hi, I'm the maintainer and a primary author of a postgresql client
> library
> for Haskell, called postgresql-simple, and I recently investigated
> improving support for VALUES expressions in this library. As a result,
> I'd
> like to suggest two changes to postgresql:
>
> 1
2014-02-26 20:36 GMT+01:00 Andrew Dunstan :
>
> On 02/26/2014 01:51 PM, Josh Berkus wrote:
>
>> On 02/26/2014 10:15 AM, salah jubeh wrote:
>>
>>> I think, there is a difference between optional parameters and default
>>> parameter values. So, my suggestion would be something like this.
>>> SELECT
On Wed, Feb 26, 2014 at 12:05 PM, Josh Berkus wrote:
> On 02/26/2014 09:57 AM, Merlin Moncure wrote:
>> What is not going to be so clear for users (particularly without good
>> supporting documentation) is how things break down in terms of usage
>> between hstore and jsonb.
>
> Realistically? Onc
On 02/26/2014 01:51 PM, Josh Berkus wrote:
On 02/26/2014 10:15 AM, salah jubeh wrote:
I think, there is a difference between optional parameters and default
parameter values. So, my suggestion would be something like this.
SELECT default_test(1,3, DEFAULT); -- match function number 1
SELECT d
Christian,
Thanks for working on all of this and dealing with the requests for
updates and changes, as well as for dealing very professionally with an
inappropriate and incorrect remark. Unfortunately, mailing lists can
make communication difficult and someone's knee-jerk reaction (not
referring
On Wed, Feb 26, 2014 at 1:54 PM, Josh Berkus wrote:
> And thank you for writing that driver!
>
You are welcome!
I have no opinion about your request for VALUES() stuff, though. It
> looks fairly complex as far as grammar and libpq is concerned.
>
Actually, my suggestions wouldn't necessarily
On 02/26/2014 10:47 AM, Leon Smith wrote:
> Hi, I'm the maintainer and a primary author of a postgresql client library
> for Haskell, called postgresql-simple, and I recently investigated
> improving support for VALUES expressions in this library. As a result, I'd
> like to suggest two changes
On 02/26/2014 10:15 AM, salah jubeh wrote:
> I think, there is a difference between optional parameters and default
> parameter values. So, my suggestion would be something like this.
> SELECT default_test(1,3, DEFAULT); -- match function number 1
>
> SELECT default_test(1,3); -- match the funct
Hi, I'm the maintainer and a primary author of a postgresql client library
for Haskell, called postgresql-simple, and I recently investigated
improving support for VALUES expressions in this library. As a result, I'd
like to suggest two changes to postgresql:
1. Allow type specifications ins
On 2014-02-26 15:30:55 -0300, Alvaro Herrera wrote:
> Andres Freund escribió:
>
> > I am wondering about the related situation of GetOldestXmin()
> > callers. There's a fair bit of duplicated logic in the callers, before
> > but especially after this patchset. What about adding 'Relation rel'
> >
salah jubeh wrote
> Hello,
>
> I find default values confusing when a function is overloaded, below is an
> example.
>
>
> CREATE OR REPLACE FUNCTION default_test (a INT DEFAULT 1, b INT DEFAULT 1,
> C INT DEFAULT 1) RETURNS INT AS
> $$
> BEGIN
> RETURN a+b+c;
> END;
> $$
> LANG
Andres Freund escribió:
> I am wondering about the related situation of GetOldestXmin()
> callers. There's a fair bit of duplicated logic in the callers, before
> but especially after this patchset. What about adding 'Relation rel'
> parameter instead of `allDbs' and `systable'? That keeps the log
Hello,
I find default values confusing when a function is overloaded, below is an
example.
CREATE OR REPLACE FUNCTION default_test (a INT DEFAULT 1, b INT DEFAULT 1, C
INT DEFAULT 1) RETURNS INT AS
$$
BEGIN
RETURN a+b+c;
END;
$$
LANGUAGE 'plpgsql';
CREATE OR REPLACE FUNCTION
On 02/26/2014 09:57 AM, Merlin Moncure wrote:
> On Wed, Feb 26, 2014 at 11:41 AM, Josh Berkus wrote:
>> On 02/26/2014 07:02 AM, Merlin Moncure wrote:
>>> On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing
>>> wrote:
It is not in any specs, but nevertheless all major imlementations do it and
>>>
On Wed, Feb 26, 2014 at 11:41 AM, Josh Berkus wrote:
> On 02/26/2014 07:02 AM, Merlin Moncure wrote:
>> On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing wrote:
>>> It is not in any specs, but nevertheless all major imlementations do it and
>>> some code depends on it.
>>> IIRC, this behaviour is cu
On 02/26/2014 06:13 PM, Alvaro Herrera wrote:
There's one thing that rubs me the wrong way about all this
functionality, which is that we've named it "huge TLB pages". That is
wrong -- the TLB pages are not huge. In fact, as far as I understand,
the TLB doesn't have pages at all. It's the pag
On 02/25/2014 08:07 PM, Craig Ringer wrote:
> 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 agr
On 02/26/2014 07:02 AM, Merlin Moncure wrote:
> On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing wrote:
>> It is not in any specs, but nevertheless all major imlementations do it and
>> some code depends on it.
>> IIRC, this behaviour is currently also met only by json and not by jsonb.
>
> Yes: Th
On 2014-02-24 17:06:53 -0500, Robert Haas wrote:
> - heap_page_prune_opt(scan->rs_rd, buffer, RecentGlobalXmin);
> + if (IsSystemRelation(scan->rs_rd)
> + || RelationIsAccessibleInLogicalDecoding(scan->rs_rd))
> + heap_page_prune_opt(scan->rs_rd, buffer, Rece
There's one thing that rubs me the wrong way about all this
functionality, which is that we've named it "huge TLB pages". That is
wrong -- the TLB pages are not huge. In fact, as far as I understand,
the TLB doesn't have pages at all. It's the pages that are huge, but
those pages are not TLB pa
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> I (plan to) use custom-scan of course. Once a relation is referenced
> and optimizer decided GPU acceleration is cheaper, associated custom-
> scan node read the data from underlying relation (or in-memory cache
> if exists) then move to the shared me
Hi,
While testing event triggers support for CREATE RULE, I noticed that
existing code does not deparse whole-row references correctly:
postgres=# create table f (a int);
CREATE TABLE
postgres=# create table g (other f);
CREATE TABLE
postgres=# create rule f as on insert to f do also (insert into
On 02/26/2014 02:17 AM, Christophe Pettus wrote:
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
On 2014-02-26 15:15:00 +, Simon Riggs wrote:
> On 26 February 2014 13:38, Andres Freund wrote:
> > Hi,
> >
> > On 2014-02-26 07:32:45 +, Simon Riggs wrote:
> >> > * This definitely should include isolationtester tests actually
> >> > performing concurrent ALTER TABLEs. All that's current
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> IIUC, his approach was integration of join-pushdown within FDW APIs,
> however, it does not mean the idea of remote-join is rejected.
For my part, trying to consider doing remote joins *without* going
through FDWs is just nonsensical. What are you j
On 26 February 2014 13:38, Andres Freund wrote:
> Hi,
>
> On 2014-02-26 07:32:45 +, Simon Riggs wrote:
>> > * This definitely should include isolationtester tests actually
>> > performing concurrent ALTER TABLEs. All that's currently there is
>> > tests that the locklevel isn't too high, b
On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing wrote:
> 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 - pe
On Fri, Feb 21, 2014 at 08:17:36PM -0500, Tom Lane wrote:
> I wrote:
> > Craig Ringer writes:
> >> So I'd like to confirm that this issue doesn't affect 9.1.
>
> > It doesn't. I suspect it has something to do with 173e29aa5 or one
> > of the nearby commits in backend/regex/.
>
> Indeed, git bis
On Tue, Feb 25, 2014 at 10:07 PM, Craig Ringer wrote:
> 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. N
Hi,
On 26/02/14 14:34, Heikki Linnakangas wrote:
> That still says "The setting is ignored on other systems". That's not quite
> true: as explained later in the section, if you set huge_tlb_pages=on and
> the platform doesn't support it, the server will refuse to start.
I added a sentence about i
Hi,
On 2014-02-26 07:32:45 +, Simon Riggs wrote:
> > * This definitely should include isolationtester tests actually
> > performing concurrent ALTER TABLEs. All that's currently there is
> > tests that the locklevel isn't too high, but not that it actually works.
>
> There is no concurren
On 02/26/2014 10:35 AM, Christian Kruse wrote:
On 25/02/14 19:28, Andres Freund wrote:
I think all that's needed is to cut the first paragraphs that generally
explain what huge pages are in some detail from the text and make sure
the later paragraphs don't refer to the earlier ones.
Attached y
Hello, Robert.
You wrote:
RH> 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 r
2014-02-24 02:44, Andreas Karlsson :
> Note: The patches do not apply anymore due to changes to
> src/backend/utils/adt/Makefile.
I will fix it on the next version.
> I see, thanks for the explanation. But I am still not very fond of how that
> code is written since I find it hard to verify the
Hi Robert,
On 25/02/14 12:37, Robert Haas wrote:
> 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 useful instead
> of something lame.
Hm, thought
Hi Peter,
after a night of sleep I'm still not able to swallow the pill. To be
honest I'm a little bit angry about this accusation.
I didn't mean to copy from the Debian wiki and after re-checking the
text again I'm still convinced that I didn't.
Of course the text SAYS something similar, but th
> 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 value or by turning off index_scan, so that
2014-02-26 17:31 GMT+09:00 Kouhei Kaigai :
> IIUC, his approach was integration of join-pushdown within FDW APIs,
> however, it does not mean the idea of remote-join is rejected.
> I believe it is still one of our killer feature if we can revise the
> implementation.
>
> Hanada-san, could you put t
> > > If you're looking to just use GPU acceleration for improving
> > > individual queries, I would think that Robert's work around backend
> > > workers would be a more appropriate way to go, with the ability to
> > > move a working set of data from shared buffers and on-disk
> > > representation
On 02/25/2014 11:32 PM, Tom Lane wrote:
Meh. A progress-reporting feature has use when the tool is working
towards completion of a clearly defined task. In the case of pgbench,
if you told it to run for -T 60 seconds rather than -T 10 seconds,
that's probably because you don't trust a 10-second
Alex Hunsaker writes:
> 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 FREETM
Hi,
On 25/02/14 19:28, Andres Freund wrote:
> I think all that's needed is to cut the first paragraphs that generally
> explain what huge pages are in some detail from the text and make sure
> the later paragraphs don't refer to the earlier ones.
Attached you will find a new version of the patch.
> * 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 en
Hi,
Peter Eisentraut writes:
> I'm massively in favor of this feature. (I had started writing it about
> three times myself.)
Thanks!
> The problem I see, however, is that most extensions, by recommendation,
> set module_pathname = '$libdir/pgfoo', and so relocating the control
> files will st
* Shigeru Hanada (shigeru.han...@gmail.com) wrote:
> Perhaps he meant to separate patches based on feature-based rule. IMO
> if exposing utilities is essential for Custom Scan API in practical
> meaning, IOW to implement and maintain an extension which implements
> Custom Scan API, they should be
2014-02-26 16:46 GMT+09:00 Kouhei Kaigai :
>> Just to come back to this- the other two "contrib module" patches, at least
>> as I read over their initial submission, were *also* patching portions of
>> backend code which it was apparently discovered that they needed. That's
>> a good bit of my com
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> > Just to come back to this- the other two "contrib module" patches, at least
> > as I read over their initial submission, were *also* patching portions of
> > backend code which it was apparently discovered that they needed. That's
> > a good bit of
93 matches
Mail list logo
