On Tue, 2007-10-16 at 00:34 -0400, Tom Lane wrote:
Seems like this needs more comments about what's happening, rather
than less ...
Fair point.
Also, it looks to me like the plan node's own resultslot might never be
assigned to at all, when the subplan returns zero rows. Does this
corner
Applied, thanks.
-Neil
On Fri, 2007-12-07 at 18:48 +1100, FAST PostgreSQL wrote:
Rgds,
Arul Shaji
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining
On Mon, 2007-12-10 at 19:27 +, Dave Page wrote:
Whilst doing some profiling of the server I found it useful to add an
option to pgbench to introduce a delay between client connection setup
and the start of the benchmark itself to allow me time to attach the
profiler to one of the backends.
On Mon, 2007-12-10 at 19:12 -0500, Greg Smith wrote:
I just poked around the
documentation a bit and I didn't find anything that cleared up which
options you can pass from a client
http://www.postgresql.org/docs/8.2/static/libpq-envars.html
Which says only PGOPTIONS sets additional run-time
Attached is a patch which fixes an oversight in _outAgg(): the
grpColIdx and grpOperators fields of the Agg struct were not emitted
by _outAgg(). I don't see any good reason to omit this information.
Note that while the grpOperators field was added during the 8.3 devel
cycle, the grpColIdx field
On Tue, 2008-01-08 at 23:08 -0500, Tom Lane wrote:
Hmm, I think that must be my fault, but I'm not sure how it got by me
... I'm usually pretty careful about adding outfuncs support when I add
a node field. Patch looks good, please apply.
Applied to HEAD.
-Neil
On Mon, 2008-01-14 at 20:55 -0500, Tom Lane wrote:
Any thoughts whether to apply or not?
Seems like a much more sane approach to me -- +1.
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Attached is an updated version of Greg Stark's patch to add support for
the non-recursive variant of the SQL99 WITH clause[1]. I haven't looked
at the actual functionality of the patch yet (which is quite trivial) --
I just fixed up bitrot and the like. I also removed support for
RECURSIVE and the
On Sun, 2008-01-27 at 09:17 +, Gregory Stark wrote:
Tom's feeling at the time was that even though it was providing something from
the standard, it wasn't actually allowing the user to do anything he couldn't
before.
I think this feature has value:
(1) This is SQL-standard syntax (and not
On Sun, 2008-01-27 at 12:36 -0500, Tom Lane wrote:
Both of the above arguments hold water only if we implement compatible
*semantics*, not merely syntax, so I find them unconvincing at this
stage.
How are the semantics of the proposed patch incompatible with the SQL
spec or the implementations
On Sun, 2008-01-27 at 21:54 +, Gregory Stark wrote:
I liked the synchronized_sequential_scans idea myself.
I think that's a bit too long. How about synchronized_scans, or
synchronized_seqscans?
-Neil
---(end of broadcast)---
TIP 6: explain
On Mon, 2008-01-28 at 17:27 +1100, Russell Smith wrote:
Can somebody explain why it's important to load with
synchronized_scanning off?
*Loading* with synchronized scanning off is not important (and is not
implemented by the patch).
*Dumping* with synchronized scanning off is necessary to
On Tue, 2008-01-29 at 13:20 -0500, Tom Lane wrote:
The reason it was kept was to override the search path --- unqualified
NUMERIC will always be taken as pg_catalog.numeric even if you have some
other type numeric in front of it.
It should be possible to implement this behavior without
On Mon, 2008-02-25 at 21:00 -0500, Tom Lane wrote:
I find this part of the patch to be a seriously bad idea.
nodeFunctionscan has no right to assume that the function has returned
an expendable tupdesc; indeed, I would think that the other case is
more nearly what's expected by the API for
On Tue, 2008-02-26 at 03:13 -0500, Tom Lane wrote:
It's OK in the built-in SRFs is disastrously different from It's OK.
Right, I never said that, I was just commenting on your view that the
predominant use-case for SRFs is returning refcounted tupdescs.
You didn't comment on my proposed
On Tue, 2008-02-26 at 00:17 -0800, Neil Conway wrote:
You didn't comment on my proposed solution (FreeTupleDesc() iff refcount
== -1).
Attached is a revised version of this patch. It makes the
FreeTupleDesc() change described above, and fixes a bug: in
SRF_RETURN_DONE(), we need to be sure
On Tue, 2008-02-26 at 12:09 -0800, Neil Conway wrote:
I'd like to apply this change to back branches reasonably soon, so if
you have a better way to do the FreeTupleDesc() hack, let me know.
Barring any objections, I'll apply this to HEAD and back branches
tonight or tomorrow.
-Neil
On Wed, 2008-02-27 at 15:07 -0500, Tom Lane wrote:
Negative refcount does not prove that the SRF itself hasn't
still got a pointer to the tupdesc.
That sounds quite bizarre. The SRF has already finished execution at
this point, so keeping a pointer to the tupledesc around would only make
sense
Attached is a patch that allows an array of Datums + nulls to be
inserted into a tuplestore without first creating a HeapTuple, per
recent suggestion on -hackers. This avoids making an unnecessary copy.
There isn't a really analogous optimization to be applied to tuplesort:
it takes either a TTS,
On Thu, 2008-02-28 at 16:37 -0800, Neil Conway wrote:
Attached is a patch that allows an array of Datums + nulls to be
inserted into a tuplestore without first creating a HeapTuple, per
recent suggestion on -hackers. This avoids making an unnecessary copy.
Applied to HEAD.
-Neil
--
Sent
Attached is a refreshed patch that makes integer datetimes the default.
Platforms that don't have a working 64-bit integer type will fail to
configure by default; they can specify --disable-integer-datetimes to
switch back to using floating-point based datetimes.
Barring any objections, I'll
On Sat, 2008-03-22 at 21:35 -0400, Tom Lane wrote:
After a quick read, looks sane except for one stylistic gripe:
in exec_stmt_return_next, you added an initialization of tuple = NULL
in order to remove a couple of lines like
tuple = NULL; /* keep compiler quiet */
On Tue, 2008-03-18 at 16:19 -0300, Alvaro Herrera wrote:
The other approach, of course, is to just keep all the code in tqual.c
and not create a separate module at all. Opinions? I prefer to keep
them separate, but I'm not wedded to it if there's any strong reason not
to do it. Also, the
On Tue, 2008-03-25 at 15:45 -0500, Robert Lor wrote:
Attached is the doc patch for the recent DTrace changes
Applied, thanks.
-Neil
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
On Tue, 2008-03-25 at 12:54 -0700, Neil Conway wrote:
Barring any objections, I'll apply this to HEAD tomorrow.
Applied to HEAD.
-Neil
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
On Fri, 2008-05-16 at 19:41 -0400, Tom Lane wrote:
Applied with corrections. Most notably, since ALTER SEQUENCE RESTART
is nontransactional like most other ALTER SEQUENCE operations, I
rearranged things to try to ensure that foreseeable failures like
deadlock and lack of permissions would be
Attached is a patch that makes some minor changes to the text emitted by
the new help command. Previous output:
postgres=# help
You are using psql, the command-line interface to PostgreSQL.
\? for psql help
\h or \help for SQL help
\g or ; to execute a query
\q
On Tue, 2008-06-03 at 13:03 +0200, Pavel Stehule wrote:
this patch add support of table functions syntax like ANSI SQL 2003.
I'm not necessarily opposed to this, but I wonder if we really need
*more* syntax variants for declaring set-returning functions. The
existing patchwork of features is
On Tue, 2008-06-10 at 06:42 +0200, Pavel Stehule wrote:
internally is table functions implemenation identical with SRF.
It's not the internals that I'm concerned about.
Semantically is far - user's doesn't specify return type (what is from
PostgreSQL), but specifies return table, what is more
On Mon, 2008-06-09 at 00:25 -0700, Neil Conway wrote:
Attached is a patch that makes some minor changes to the text emitted by
the new help command.
Applied to HEAD.
-Neil
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
On Fri, 2008-06-13 at 01:49 -0300, Euler Taveira de Oliveira wrote:
Attached is a small patch to fix some typos in probes.d path.
Applied, thanks.
-Neil
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
On Mon, 2008-06-23 at 03:52 +1000, Thomas Lee wrote:
* Should it be possible to set this new variable via a command-line
option ala shared_buffers?
I would say not: most parameters cannot be set by special command-line
parameters, and this one is not important enough to warrant special
On Tue, 2008-07-08 at 14:51 -0400, Tom Lane wrote:
I'd still like to take a look.
I was tasked with reviewing this for the current commit fest, although
so far I've just been working on grokking the rest of the GIN code. But
if you'd like to review it instead, that's fine with me.
-Neil
--
801 - 833 of 833 matches
Mail list logo