[HACKERS] Changes to stringinfo.c

Hi, I'm just looking at the changed code in commit 3147acd63e0135aff9a6c4b01d861251925d97d9 and I'm wondering if we should perhaps test the performance of this before assuming too much that it is an improvement. I'm a bit concerned that now if there is not enough space in the buffer that we only n

[HACKERS] dsm use of uint64

When I wrote the dynamic shared memory patch, I used uint64 everywhere to measure sizes - rather than, as we do for the main shared memory segment, Size. This now seems to me to have been the wrong decision; I'm finding that it's advantageous to make dynamic shared memory behave as much like the m

Re: [HACKERS] logical changeset generation v6.4

On Fri, Oct 25, 2013 at 10:58 AM, Andres Freund wrote: > So, I am currently wondering about how to store the "old" tuple, based > on this. Currently it is stored using the TupleDesc of the index the old > tuple is based on. But if we want to allow transporting the entire tuple > that obviously can

Re: [HACKERS] CLUSTER FREEZE

On 25 October 2013 01:17, Josh Berkus wrote: > On 10/24/2013 04:55 PM, Robert Haas wrote: > > I wonder if we should go so far as to make this the default behavior, > > instead of just making it an option. > > +1 from me. Can you think of a reason you *wouldn't* want to freeze? Ok, I attach an

Re: [HACKERS] Failure while inserting parent tuple to B-tree is not fun

On 22.10.2013 19:55, Heikki Linnakangas wrote: I fixed the the same problem in GiST a few years back, by making it tolerate missing downlinks, and inserting them lazily. The B-tree code tolerates them already on scans, but gets confused on insertion, as seen above. I propose that we use the same

Re: [HACKERS] Additional information on log_line_prefix

On 10/25/2013 01:50 PM, Emanuel Calvo wrote: Hi guys, I'm working on a quick convertion script for query reviews and I wonder if a feature request to add the following values will be possible: %D = duration %L = lock_time (lock only for this query) %E = estimated rows %R = total rows

Re: [HACKERS] Additional information on log_line_prefix

emanuel_calvo wrote > %E = estimated rows How would you expect this to work? This information seems mostly useless without the context of a full EXPLAIN output. > %T = temporal tables used I am guessing you mean "temporary", not temporal - the later also being known as "time oriented" David

[HACKERS] Additional information on log_line_prefix

Hi guys, I'm working on a quick convertion script for query reviews and I wonder if a feature request to add the following values will be possible: %D = duration %L = lock_time (lock only for this query) %E = estimated rows %R = total rows returned %B = total bytes sent %T = temporal tabl

Re: [HACKERS] Detection of nested function calls

On Fri, Oct 25, 2013 at 10:18 AM, Tom Lane wrote: > Hugo Mercier writes: >> PostGIS functions that manipulate geometries have to unserialize their >> input geometries from the 'flat' varlena representation to their own, >> and serialize the processed geometries back when returning. >> But in such

Re: [HACKERS] psql should show disabled internal triggers

On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: > On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote: > > --On 18. September 2013 13:52:29 +0200 Andres Freund > > wrote: > > > > >If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually > > >re-enable the disabled triggers it

Re: [HACKERS] CLUSTER FREEZE

On 10/24/2013 07:19 PM, Tom Lane wrote: > In any case, it's very far from obvious to me that CLUSTER ought > to throw away information by default, which is what you're proposing. The problem here is that you're thinking of the 1/10 of 1% of our users who have a serious PostgreSQL failure and post

Re: [HACKERS] Detection of nested function calls

Hugo Mercier writes: > Le 25/10/2013 17:20, Tom Lane a écrit : >> How do you tell the difference between >> >> foo(col1, bar(col2)) >> foo(bar(col1), col2) > Still not sure to understand ... > I assume foo() takes two argument of type A. > bar() can take one argument of A or another type B. I w

[HACKERS] LISTEN / NOTIFY enhancement request for Postgresql

Hi pgsql-hackers, The LISTEN / NOTIFY feature (along with the pg_notify() function) is a unique feature that differentiates Postgresql from nearly all other relational database systems. With the exception of SQL Server, I know of no other RDBMSs that allow a client to be asynchronously notifi

Re: [HACKERS] Detection of nested function calls

Le 25/10/2013 17:20, Tom Lane a écrit : > Hugo Mercier writes: >> Le 25/10/2013 16:18, Tom Lane a écrit : > How do you tell the difference between > >foo(col1, bar(col2)) >foo(bar(col1), col2) > Still not sure to understand ... I assume foo() takes two argument of type A. bar()

Re: [HACKERS] Detection of nested function calls

Hugo Mercier writes: > Le 25/10/2013 16:18, Tom Lane a écrit : >> However, this seems like a completely wrong way to go at it. In the first >> place, it wouldn't help for situations like a complex value stored in a >> plpgsql variable. In the second, I don't think that what you are >> describing

Re: [HACKERS] Detection of nested function calls

On 2013-10-25 11:01:28 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-10-25 10:18:27 -0400, Tom Lane wrote: > >> I think the right way to attack it is to create some way for a Datum > >> value to indicate, at runtime, whether it's a flat value or an in-memory > >> representation. > >

Re: [HACKERS] Detection of nested function calls

Le 25/10/2013 16:18, Tom Lane a écrit : > Hugo Mercier writes: >> PostGIS functions that manipulate geometries have to unserialize their >> input geometries from the 'flat' varlena representation to their own, >> and serialize the processed geometries back when returning. >> But in such nested cal

Re: [HACKERS] Detection of nested function calls

Andres Freund writes: > On 2013-10-25 10:18:27 -0400, Tom Lane wrote: >> I think the right way to attack it is to create some way for a Datum >> value to indicate, at runtime, whether it's a flat value or an in-memory >> representation. > That sounds reasonable, and we have most of the infrastruc

Re: [HACKERS] logical changeset generation v6.4

Hi, On 2013-10-22 16:07:16 +0200, Andres Freund wrote: > On 2013-10-21 20:16:29 +0200, Andres Freund wrote: > > Current draft is: > > ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL|DEFAULT > > ALTER TABLE ... REPLICA IDENTITY USING INDEX ...; > > > > which leaves the door open for > > > > ALTER T

Re: [HACKERS] Detection of nested function calls

On 2013-10-25 10:18:27 -0400, Tom Lane wrote: > I think the right way to attack it is to create some way for a Datum > value to indicate, at runtime, whether it's a flat value or an in-memory > representation. Any given function returning the type could choose to > return either representation. T

Re: [HACKERS] New committer

Tatsuo Ishii writes: > Hi pgpool hackers, > Muhammad Usama did great job in restructuring pgpool source code. And > now he is working on incorporating PostgreSQL's exception and memory > manager. I believe now is the time to add him to our one of committers > and I just have done so. I assume thi

Re: [HACKERS] Detection of nested function calls

Hugo Mercier writes: > PostGIS functions that manipulate geometries have to unserialize their > input geometries from the 'flat' varlena representation to their own, > and serialize the processed geometries back when returning. > But in such nested call queries, this serialization-unserialization

Re: [HACKERS] RULE regression test fragility?

Andres Freund wrote: > On 2013-10-24 09:22:52 -0400, Tom Lane wrote: > > Andres Freund writes: > > > FWIW, I've repeatedly now thought that it'd make maintaining/updating > > > patches easier if we switched that query into unaligned tuple only (\a > > > \t) mode. That would remove the frequent con

Re: [HACKERS] Example query causing param_info to be set in plain rel path

Ashutosh Bapat writes: > In order to test various cases of LATERAL join in Postgres-XC, I am trying > to find a query where RelOptInof->lateral_relids would get set for plain > base relations. I think you need a lateral reference in a function or VALUES FROM-item. As you say, plain sub-selects ar

Re: [HACKERS] proposal: lob conversion functionality

fixed documentation Regards Pavel 2013/10/24 Heikki Linnakangas > On 22.10.2013 13:55, Pavel Stehule wrote: > >> 2013/10/21 Noah Misch >> >>> If you're prepared to change the function names and add the >>> subset-oriented >>> functions, I would appreciate that. >>> >>> here is patch >> > > l

Re: [HACKERS] UNION ALL on partitioned tables won't use indices.

On Thu, Oct 24, 2013 at 6:39 AM, Kyotaro HORIGUCHI wrote: > Hello, Sorry that it's been a while.. > > 1. Observed symptom > > As you know, UNION ALL accompanied with ORDER BY uses indexes if > available. > >> uniontest=# EXPLAIN SELECT * FROM c11 UNION ALL SELECT * FROM c12 ORDER BY a; >>

Re: [HACKERS] CLUSTER FREEZE

On Thu, Oct 24, 2013 at 10:19 PM, Tom Lane wrote: > Robert Haas writes: >> I wonder if we should go so far as to make this the default behavior, >> instead of just making it an option. > > In that case you'd have to invent a NOFREEZE keyword, no? Ick. Only if we think anyone would ever NOT want

Re: [HACKERS] CLUSTER FREEZE

On 2013-10-25 09:13:20 -0400, Robert Haas wrote: > On Fri, Oct 25, 2013 at 2:12 AM, Andres Freund wrote: > > On 2013-10-24 17:17:22 -0700, Josh Berkus wrote: > >> On 10/24/2013 04:55 PM, Robert Haas wrote: > >> > On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus wrote: > >> >> On 10/23/2013 09:58 PM,

Re: [HACKERS] CLUSTER FREEZE

On Fri, Oct 25, 2013 at 2:12 AM, Andres Freund wrote: > On 2013-10-24 17:17:22 -0700, Josh Berkus wrote: >> On 10/24/2013 04:55 PM, Robert Haas wrote: >> > On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus wrote: >> >> On 10/23/2013 09:58 PM, Amit Kapila wrote: >> >>> I wonder why anyone would like to

Re: [HACKERS] Detection of nested function calls

2013/10/25 Hugo Mercier > Le 25/10/2013 14:29, Pavel Stehule a écrit : > > Hello > > > > > > 2013/10/25 Hugo Mercier > >. > > > > I am quite new to postgresql hacking, so I'm sure there is room for > > improvements. But, what about this first proposal ?

Re: [HACKERS] Detection of nested function calls

Le 25/10/2013 14:29, Pavel Stehule a écrit : > Hello > > > 2013/10/25 Hugo Mercier >. > > I am quite new to postgresql hacking, so I'm sure there is room for > improvements. But, what about this first proposal ? > > > I am not sure, if this solution i

[HACKERS] New committer

Hi pgpool hackers, Muhammad Usama did great job in restructuring pgpool source code. And now he is working on incorporating PostgreSQL's exception and memory manager. I believe now is the time to add him to our one of committers and I just have done so. Please welcome Muhammad Usama as our new co

Re: [HACKERS] Detection of nested function calls

Hello 2013/10/25 Hugo Mercier > Hi all, > > The Oslandia team is involved in PostGIS project for years, with a > current focus on PostGIS 3D support. > With PostGIS queries, nested functions calls that manipulate geometries > are quite common, e.g.: SELECT ST_Union(ST_Intersection(a.geom, > ST_

[HACKERS] Detection of nested function calls

Hi all, The Oslandia team is involved in PostGIS project for years, with a current focus on PostGIS 3D support. With PostGIS queries, nested functions calls that manipulate geometries are quite common, e.g.: SELECT ST_Union(ST_Intersection(a.geom, ST_Buffer(b.geom, 50))) PostGIS functions that ma

Re: [HACKERS] Location for external scripts for Extensions?

On 10/24/13, 5:37 PM, Josh Berkus wrote: > On 10/24/2013 02:36 PM, Peter Eisentraut wrote: >> On 10/22/13, 2:27 PM, Josh Berkus wrote: >>> pg_partman has several external (python) scripts which help the >>> extension, located in /extras/ in its source. The problem currently is >>> that if you inst

Re: [HACKERS] logical changeset generation v6.2

On 2013-10-21 16:15:58 +0200, Andres Freund wrote: > > I don't think I understand exactly what you have in mind for (2); can > > you elaborate? I have always thought that having a > > WaitForDecodingToCatchUp() primitive was a good way of handling > > changes that were otherwise too difficult to t

Re: [HACKERS] logical changeset generation v6.2

On 2013-10-24 10:59:21 -0400, Robert Haas wrote: > On Tue, Oct 22, 2013 at 2:13 PM, Andres Freund wrote: > > On 2013-10-22 13:57:53 -0400, Robert Haas wrote: > >> On Tue, Oct 22, 2013 at 1:08 PM, Andres Freund > >> wrote: > >> >> That strikes me as a flaw in the implementation rather than the id

Re: [HACKERS] Patch for fail-back without fresh backup

On 2013-10-24 22:57:29 +0200, Magnus Hagander wrote: > In fact I've been considering suggesting we might want to retire the > difference between archive and hot_standby as wal_level, because the > difference is usually so small. And the advantage of hot_standby is in > almost every case worth it. E

Re: [HACKERS] Patch for fail-back without fresh backup

On 2013-10-24 13:51:52 -0700, Josh Berkus wrote: > On 10/24/2013 01:14 PM, Heikki Linnakangas wrote: > > One extra WAL record whenever a hint bit is set on a page, for the first > > time after a checkpoint. In other words, a WAL record needs to be > > written in the same circumstances as with page

[HACKERS] Document update in alter_foreign_data_wrapper.sgml

Hi, ISTM the document in alter_foreign_data_wrapper.sgml and the comment in foreigncmds.c should be updated. Please find attached a patch. Thanks, Best regards, Etsuro Fujita fdw-doc-update.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

[HACKERS] Example query causing param_info to be set in plain rel path

Hi All, In order to test various cases of LATERAL join in Postgres-XC, I am trying to find a query where RelOptInof->lateral_relids would get set for plain base relations. I tried various examples like below. But none of them was able to set lateral_relids in RelOptInfo of the involved relations. I