Re: [HACKERS] Does the SQL standard actually define LATERAL anywhere?

2012/9/1 Tom Lane : > As implemented in HEAD, LATERAL means to run a nestloop in which the > lateral-referencing query is run once per row of the referenced table, > and the resulting rows are joined to just that row of the referenced > table. So for example: > > # select * from (values (2),(4)) v

Re: [HACKERS] WIP patch for LATERAL subqueries

Merlin Moncure writes: > This is just awesome. Anyways, I was looking around the docs for > references to the old methodology of select list SRF function calls. > This paragraph: > http://www.postgresql.org/docs/devel/static/xfunc-sql.html#XFUNC-SQL-FUNCTIONS-RETURNING-SET > could probably use s

[HACKERS] Does the SQL standard actually define LATERAL anywhere?

As implemented in HEAD, LATERAL means to run a nestloop in which the lateral-referencing query is run once per row of the referenced table, and the resulting rows are joined to just that row of the referenced table. So for example: # select * from (values (2),(4)) v(x), lateral generate_series(1,

[HACKERS] too much pgbench init output

When initializing a large database, pgbench writes tons of "%d tuples done" lines. I propose to change this to a sort of progress counter that stays on the same line, as in the attached patch. diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c index 00cab73..b5f3054 100644 --- a/co

Re: [HACKERS] effective_io_concurrency

On Thu, Aug 30, 2012 at 1:25 PM, Peter Geoghegan wrote: > Just how helpful is effective_io_concurrency? Did someone produce a > benchmark at some point? Attached is a benchmark I put together a while ago. I don't know how close to "real world" it might be. I haven't seen it in the wild, but I'

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On 08/31/2012 06:39 PM, Tom Lane wrote: Andrew Dunstan writes: I'm not sure what we need to do to progress on this, especially re the back branches. The calendar might help us here. 9.2 is due to wrap next week, but it will likely be a couple of months before we contemplate new back-branch

Re: [HACKERS] _USE_32BIT_TIME_T Patch

Andrew Dunstan writes: > I'm not sure what we need to do to progress on this, especially re the > back branches. The calendar might help us here. 9.2 is due to wrap next week, but it will likely be a couple of months before we contemplate new back-branch releases. So we could push a fix that

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On 08/31/2012 03:36 PM, Tom Lane wrote: Dave Page writes: As a side note - I'm not sure why _USE_32BIT_TIME_T was removed in the first place; it was added specifically to avoid this sort of problem, though iirc at the time we were thinking of extensions like Slony and PostGIS being built with

Re: [HACKERS] PATCH: pgbench - aggregation of info written into log

On Thu, Aug 30, 2012 at 5:55 PM, Tomas Vondra wrote: > It does, but AFAIK the "-l" means logging. I suppose > "--aggregate-interval" would be a good option name, I don't see a reason > to put there the additional word when there are other aggregated values > (e.g. num of transactions). Oh, I was

Re: [HACKERS] fairly useless psql compatibility warning?

On Fri, Aug 31, 2012 at 4:59 AM, Magnus Hagander wrote: > On Fri, Aug 31, 2012 at 4:07 AM, Peter Eisentraut wrote: >> psql has supported older servers for a great while now, so this sort of >> things seems pretty useless now: >> >> psql (9.2rc1, server 9.1.4) >> WARNING: psql version 9.2, server

Re: [HACKERS] _USE_32BIT_TIME_T Patch

Dave Page writes: > As a side note - I'm not sure why _USE_32BIT_TIME_T was removed in the > first place; it was added specifically to avoid this sort of problem, > though iirc at the time we were thinking of extensions like Slony and > PostGIS being built with Mingw for use with the VC++ built se

Re: [HACKERS] patch: shared session variables

2012/8/31 Dimitri Fontaine : > Pavel Stehule writes: >>> Pavel, you didn't say what you think about the WITH FUNCTION proposal? >> >> I don't like it - this proposal is too "lispish" - it is not SQL > > We're not doing lambda here, only extending a facility that we rely on > today. The function wo

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On 08/31/2012 01:10 PM, Dave Page wrote: On Fri, Aug 31, 2012 at 5:51 PM, Andrew Dunstan wrote: On 08/31/2012 12:41 PM, Dave Page wrote: On Fri, Aug 31, 2012 at 5:37 PM, Andrew Dunstan wrote: On 08/31/2012 12:18 PM, Dave Page wrote: On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan wrote:

Re: [HACKERS] patch: shared session variables

Pavel Stehule writes: >> Pavel, you didn't say what you think about the WITH FUNCTION proposal? > > I don't like it - this proposal is too "lispish" - it is not SQL We're not doing lambda here, only extending a facility that we rely on today. The function would be named, for one. I don't know wha

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

On Fri, Aug 31, 2012 at 5:03 PM, Heikki Linnakangas wrote: > When a cascading standby launches a new walsender, it fetches the current > recovery timeline: > > /* > * Use the recovery target timeline ID during recovery > */ > if (am_cascading_walsender) >

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On Fri, Aug 31, 2012 at 5:51 PM, Andrew Dunstan wrote: > > On 08/31/2012 12:41 PM, Dave Page wrote: >> >> On Fri, Aug 31, 2012 at 5:37 PM, Andrew Dunstan >> wrote: >>> >>> On 08/31/2012 12:18 PM, Dave Page wrote: On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan wrote: > > O

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On 08/31/2012 12:41 PM, Dave Page wrote: On Fri, Aug 31, 2012 at 5:37 PM, Andrew Dunstan wrote: On 08/31/2012 12:18 PM, Dave Page wrote: On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan wrote: On 08/31/2012 11:14 AM, Dave Page wrote: On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan wrote:

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On Fri, Aug 31, 2012 at 5:37 PM, Andrew Dunstan wrote: > > On 08/31/2012 12:18 PM, Dave Page wrote: >> >> On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan >> wrote: >>> >>> On 08/31/2012 11:14 AM, Dave Page wrote: On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan wrote: > > O

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On 08/31/2012 12:18 PM, Dave Page wrote: On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan wrote: On 08/31/2012 11:14 AM, Dave Page wrote: On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan wrote: On 08/31/2012 11:05 AM, Dave Page wrote: I've added this to the release blockers section for 9.2 o

Re: [HACKERS] Use of systable_beginscan_ordered in event trigger patch

Tom Lane writes: > Or maybe we should disable event triggers altogether in standalone mode? Would something as simple as the attached work for doing that? (passes make check and I did verify manually that postmaster --single is happy with it and skipping Event Triggers). Regards, -- Dimitri Fon

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On Fri, Aug 31, 2012 at 5:18 PM, Dave Page wrote: > On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan wrote: >> >> On 08/31/2012 11:14 AM, Dave Page wrote: >>> >>> On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan >>> wrote: On 08/31/2012 11:05 AM, Dave Page wrote: > > I've added t

Re: [HACKERS] pg_upgrade's exec_prog() coding improvement

On 08/31/2012 10:52 AM, Andrew Dunstan wrote: On 08/24/2012 11:44 AM, Alvaro Herrera wrote: Again, win32 testing would be welcome. Sadly, buildfarm does not run pg_upgrade's "make check". Yesterday I added a new module to the buildfarm client code to run this (

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On Fri, Aug 31, 2012 at 4:57 PM, Andrew Dunstan wrote: > > On 08/31/2012 11:14 AM, Dave Page wrote: >> >> On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan >> wrote: >>> >>> On 08/31/2012 11:05 AM, Dave Page wrote: I've added this to the release blockers section for 9.2 on the wiki,

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On 08/31/2012 11:14 AM, Dave Page wrote: On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan wrote: On 08/31/2012 11:05 AM, Dave Page wrote: I've added this to the release blockers section for 9.2 on the wiki, as without it, pl/perl is unusable on Win32. I'll have a look at it today. Thanks A

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On Fri, Aug 31, 2012 at 4:10 PM, Andrew Dunstan wrote: > > On 08/31/2012 11:05 AM, Dave Page wrote: >> >> I've added this to the release blockers section for 9.2 on the wiki, >> as without it, pl/perl is unusable on Win32. > > > > I'll have a look at it today. Thanks Andrew - minor clarification;

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On 08/31/2012 11:05 AM, Dave Page wrote: I've added this to the release blockers section for 9.2 on the wiki, as without it, pl/perl is unusable on Win32. I'll have a look at it today. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] _USE_32BIT_TIME_T Patch

I've added this to the release blockers section for 9.2 on the wiki, as without it, pl/perl is unusable on Win32. On Thu, Aug 30, 2012 at 1:39 PM, Dave Page wrote: > On Thu, Aug 30, 2012 at 6:34 AM, Owais Khan > wrote: >> Hello, >> >> We are getting crash while using plperl on Win32 as ActiveSt

Re: [HACKERS] pg_upgrade's exec_prog() coding improvement

On 08/24/2012 11:44 AM, Alvaro Herrera wrote: Again, win32 testing would be welcome. Sadly, buildfarm does not run pg_upgrade's "make check". Yesterday I added a new module to the buildfarm client code to run this (

Re: [HACKERS] compiler barriers (was: New statistics for WAL buffer dirty writes)

Was there any conclusion from these ideas? --- On Wed, Aug 1, 2012 at 11:35:56AM -0400, Robert Haas wrote: > On Wed, Aug 1, 2012 at 10:12 AM, Tom Lane wrote: > > I think you may be right that using __asm__ __volatile__ in

Re: [HACKERS] hunspell and tsearch2 ?

Hi Robert, there is a note in the pg documentation chapter 12.6.5 Ispell Dictionary *Note:*MySpell does not support compound words. Hunspell has sophisticated support for compound words. At present, PostgreSQL implements only the basic compound word operations of Hunspell. Regards

[HACKERS] rows changed in current transaction

Hi, is there any way to check if row have already been modified by the current transaction? I tried condition txid_current() = xmin, but there is problem with the savepoints. After every savepoint rows are getting higher xmin values, but txid_current() remains the same. Regards, Miroslav Simulcik

Re: [HACKERS] patch: shared session variables

2012/8/31 Dimitri Fontaine : > Pavel Stehule writes: >> a motivation for this patch was discussion about parametrised DO >> statement - and simple possibility of access to host variables (psql) >> variables from server - PL scripts. > > Pavel, you didn't say what you think about the WITH FUNCTION

Re: [HACKERS] patch: shared session variables

Pavel Stehule writes: > a motivation for this patch was discussion about parametrised DO > statement - and simple possibility of access to host variables (psql) > variables from server - PL scripts. Pavel, you didn't say what you think about the WITH FUNCTION proposal? And you didn't say how do

Re: [HACKERS] pg_dump incorrect output in plaintext mode

On Aug 28, 2012 9:59 PM, "Tom Lane" wrote: > > Magnus Hagander writes: > > On Tue, Aug 28, 2012 at 6:42 PM, Tom Lane wrote: > >> I don't see anything particularly incorrect about that. The point of > >> the --verbose switch is to track what pg_dump is doing, and if what > >> it's doing involves

Re: [HACKERS] Event Triggers reduced, v1

Robert Haas writes: > I guess I don't particularly like either of these changes. The first Fair enough. > one is mostly harmless, but I don't really see why it's any better, > and it does have the downside of traversing the string twice (once for > strlen and a second time in str_toupper) inste

Re: [HACKERS] fairly useless psql compatibility warning?

On Fri, Aug 31, 2012 at 4:07 AM, Peter Eisentraut wrote: > psql has supported older servers for a great while now, so this sort of > things seems pretty useless now: > > psql (9.2rc1, server 9.1.4) > WARNING: psql version 9.2, server version 9.1. > Some psql features might not work > > I think it

Re: [v9.3] Extra Daemons (Re: [HACKERS] elegant and effective way for running jobs inside a database)

2012/6/21 Simon Riggs : > On 21 June 2012 19:13, Jaime Casanova wrote: >> On Sun, Jun 10, 2012 at 4:15 AM, Kohei KaiGai wrote: >>> 2012/6/8 Simon Riggs : >>> I have a prototype that has some of these characteristics, so I see our work as complementary. At present, I don't thin

[HACKERS] Cascading replication and recovery_target_timeline='latest'

When a cascading standby launches a new walsender, it fetches the current recovery timeline: /* * Use the recovery target timeline ID during recovery */ if (am_cascading_walsender) ThisTimeLineID = GetRecoveryTargetTLI(); Comment in GetRecoveryT

Re: [HACKERS] Proof of concept: auto updatable views

On 30 August 2012 20:05, Robert Haas wrote: > On Sun, Aug 12, 2012 at 5:14 PM, Dean Rasheed > wrote: >> None of this new code kicks in for non-security barrier views, so the >> kinds of plans I posted upthread remain unchanged in that case. But >> now a significant fraction of the patch is code