This isn't the same thing as allowing RETURNING inside subqueries,
right?
greg
On 31 Oct 2008, at 07:37 PM, [EMAIL PROTECTED] (Tom Lane) wrote:
Log Message:
---
Allow SQL-language functions to return the output of an INSERT/
UPDATE/DELETE
RETURNING clause, not just a SELECT as
On Sat, 2008-11-01 at 06:13 +0200, Hannu Krosing wrote:
attached is a patch which enables plpython to recognize function with
multiple OUT params as returning a record
Overrides previous patch.
Fixed some bugs, added regression tests.
This version is quite rough, though passes tests here.
On Sat, 2008-11-01 at 15:18 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Fri, 2008-10-31 at 15:05 +, Heikki Linnakangas wrote:
Log Message:
---
Unite ReadBufferWithFork, ReadBufferWithStrategy, and ZeroOrReadBuffer
functions into one ReadBufferExtended function,
Can you test whether using the buffer access strategy is a win or a
loss? Most of that gain is probably coming from the reduction in
pinning.
Patch resnapped to HEAD, with straightforward adjustments to
compensate for Heikki's changes to the ReadBuffer interface. See
attached.
New testing
On Sat, 2008-11-01 at 13:23 -0400, Robert Haas wrote:
Can you test whether using the buffer access strategy is a win or a
loss? Most of that gain is probably coming from the reduction in
pinning.
--PATCHED--
Time: 13869.724 ms (median)
--PATCHED with BAS disabled--
Time: 14460.432 ms
Greg Stark [EMAIL PROTECTED] writes:
This isn't the same thing as allowing RETURNING inside subqueries,
right?
Right. You could fairly easily get that now by wrapping your RETURNING
query into a SQL function ... but I'm not sure that we want to advertise
that heavily, because the question of
Unofficially, well done to everybody that submitted patches in time for
Commit Fest. The queue has grown significantly over last few days and
it's clear many people have been working very hard right up to the
deadline.
Depending upon how you count it there are around 5 multi-month mega
patches,
Simon Riggs [EMAIL PROTECTED] writes:
Unofficially, well done to everybody that submitted patches in time for
Commit Fest. The queue has grown significantly over last few days and
it's clear many people have been working very hard right up to the
deadline.
Well done? It seems to me that we
Stephen, what is the status of your efforts?
The latest one I could found is the colprivs_wip.20080902.diff.gz.
Do you have any updated one?
Snowman told me this week that he was working hard on it -- he declined
to be a reviewer for that reason.
--Josh
--
Sent via pgsql-hackers mailing
Hi all,
Here is a patch that adds buffer pool statistics to the explain analyze
output revealing the number of buffer pages hit at each and every execution
step.
It uses counters from storage/buffer/bufmgr.c (I believe all that counters
are relevant for investigation of query performance).
On Sat, 2008-11-01 at 14:22 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Unofficially, well done to everybody that submitted patches in time for
Commit Fest. The queue has grown significantly over last few days and
it's clear many people have been working very hard right up
Tom,
Well done? It seems to me that we are right where we hoped not to be,
ie with a ton of barely-completed (if not self-admitted WIP) patches
dropped on us immediately before feature freeze. Today the commit fest
idea is looking like a failure.
If you don't want patches coming at given
I finally have a working version. Please have a look at the attached files
including a changed version of gram.y and and automatically created version of
preproc.y. To recreate just run awk -f parse.awk gram.y preproc.y.
Is it okay to change gram.y this way? It does run the regression suite
Heikki Linnakangas [EMAIL PROTECTED] writes:
Hmm, you're right. I think it can be made to work by storing the *end*
offset of each chunk. To find the chunk containing offset X, search for
the first chunk with end_offset X.
Yeah, that seems like it would work, and it would disentangle us
Well done? It seems to me that we are right where we hoped not to be,
ie with a ton of barely-completed (if not self-admitted WIP) patches
dropped on us immediately before feature freeze. Today the commit fest
idea is looking like a failure.
If we actually manage to ship 8.4 within six
On Friday 31 October 2008 17:01:05 Kevin Grittner wrote:
I notice there's no documentation yet. Do you have a reference to a
good description of the feature, consistent with your implementation?
Documentation will need to be added, of course, but there isn't really a lot
to describe: you
Peter Eisentraut [EMAIL PROTECTED] writes:
On Friday 31 October 2008 17:01:05 Kevin Grittner wrote:
(1) Can you compare a literal of the base type?
No, unless you create additional casts or operators.
(2) Can you explicitly cast to the base type?
There is an implicit AS ASSIGNMENT cast
Hello,
I have two concerns regarding the patch:
A) I am not sure if it is good to have a single contention point (pgss-lock
= LWLockAssign()). I guess that would impact scalability, especially on a
multi-cpu systems. I guess the real solution will come when PostgreSQL have
a pool for sql
KaiGai Kohei wrote:
I've updated my patches, it contains a few bugfixes.
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1168.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1168.patch
[3/6]
On Mon, Oct 20, 2008 at 4:42 PM, Lawrence, Ramon [EMAIL PROTECTED] wrote:
We propose a patch that improves hybrid hash join's performance for large
multi-batch joins where the probe relation has skew.
Project name: Histojoin
Patch file: histojoin_v1.patch
This patch implements the Histojoin
On Sat, 2008-11-01 at 16:21 -0400, Robert Haas wrote:
Well done? It seems to me that we are right where we hoped not to be,
ie with a ton of barely-completed (if not self-admitted WIP) patches
dropped on us immediately before feature freeze. Today the commit fest
idea is looking like a
Emmanuel Cecchet wrote:
Tom,
Well done? It seems to me that we are right where we hoped not to be,
ie with a ton of barely-completed (if not self-admitted WIP) patches
dropped on us immediately before feature freeze. Today the commit fest
idea is looking like a failure.
If you
Simon Riggs wrote:
On Sat, 2008-11-01 at 16:21 -0400, Robert Haas wrote:
Well done? It seems to me that we are right where we hoped not to be,
ie with a ton of barely-completed (if not self-admitted WIP) patches
dropped on us immediately before feature freeze. Today the commit fest
All,
This is my first patch review for PostgreSQL. I did submit a patch last
commit fest (Boyer-Moore) so I feel I should review one this commit fest.
I'm quite new to PostgreSQL so please don't rely on me totally. I'll do my
best. Heikki is also reviewing this patch which makes me feel better.
On Sat, Nov 01, 2008 at 04:21:30PM -0400, Robert Haas wrote:
It looks to me like there are at least half a dozen patches submitted
in the last week that are pretty half-baked and fall into the category
of Let's submit something before the deadline for CommitFest, in the
hopes of being allowed
Bruce Momjian wrote:
KaiGai Kohei wrote:
I've updated my patches, it contains a few bugfixes.
I was wondering why you mention the NSA (U.S. National Security Agency)
in the patch?
NSA is who create SELinux originally IIRC.
Joshua D. Drake
--
Sent via pgsql-hackers mailing list
Here is another way to solve big marathon without window functions (and
many other kinds of windowing queries, especially those that do not
specify rows preceeding etc.).
It could be considered as a very dirty hack, however it could give you an
insight on the performance of the windowed query
Without review, how can we determine the true state of a patch? I would
guess that you haven't done a review of all of them yourself to
determine that.
No, I'm talking about the comments that were made when submitting the
patch. A few people said things along the lines of this isn't really
Supposing this is true, one way to prevent that in future
commitfest-driven releases is to send them back as not ready this
time, and tell them they'll be 1st in line in the next go-round.
Agreed!
But I'll be as happy as anyone if it doesn't come to that.
...Robert
--
Sent via
Kris Jurka [EMAIL PROTECTED] writes:
On Thu, 23 Oct 2008, Kris Jurka wrote:
The problem with trying to deprecate it is that the vast majority of the
backend is still using the old interfaces, so people looking for
inspiration for their external modules will likely end up using the old
One of the long-terms goals I'm working toward is wrapping a wizard
interface around the tuning guidelines described by
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server now that
those have gone through a fair amount of peer review. Attached is a first
simple version of such a
Tom, Robert, Simon,
What, are people just on edge because of the US election?
It looks to me like the commitfest system is going really well. Of
course, we'll see how long it takes to close out 8.4. But I think we're
in much better shape than we were for 8.3. We're even in better shape
to
/ this once it's hit the archives.
Thanks,
Stephen
colprivs_wip.20081101.diff.gz
Description: Binary data
signature.asc
Description: Digital signature
Just a small correction: there should be time::text'prev_time' for the
calculations to be correct:
select *
from (
select (((case when time::text = 'prev_time' then *0* else *1*
end)+('dense_rank')::int4)::text'dense_rank')::int4 as position,
runnerid, time, time::text'prev_time'
Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
Sorry, this took way longer than planned.
Beleive me, I understand. :)
testdb=# GRANT TRUNCATE (single_col) ON test TO malory;
GRANT
This has been fixed in the attached patch.
Some privilege regression tests currently fail with your
Markus, et al,
* Stephen Frost ([EMAIL PROTECTED]) wrote:
I also wonder if you could use joins or something
to extract information about columns you're not supposed to have access
to, or where clauses, etc..
welp, I've done some additional testing and there's good news and bad, I
suppose.
2008/11/2 David Rowley [EMAIL PROTECTED]:
Obervations:
Test 3 and 5 did not seem to make use of an index to get a sorted list of
results. I disabled enable_seqscan but the planner still failed to choose
index_scan. Is there any reason for this? Perhaps I'm missing something.
Hitoshi, can you
Stephen Frost [EMAIL PROTECTED] writes:
... A case I just realized might be an issue is
doing a 'select 1 from x;' where you have *no* rights on x, or any
columns in it, would still get you the rowcount.
Well, if you have table-level select on x, I would expect that to work,
even if your privs
Hi.
I am sorry to be a very late reaction...
Hiroshi Saito [EMAIL PROTECTED] writes:
From: Magnus Hagander [EMAIL PROTECTED]
Also, the patch needs error checking. strftime() can fail, and the
multibyte conversion functions can certainly fail. That will need to be
added.
I will proposal the
39 matches
Mail list logo
