2009/5/12 Hitoshi Harada umi.tan...@gmail.com:
2009/5/11 Pavel Stehule pavel.steh...@gmail.com:
I am thinking so Grouping Sets based on CTE should be more commitable
code. It doesn't mean so your ideas are wrong, but these
optimalization should to work on CTE too.
select * from table group
Fujii Masao wrote:
On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
This is getting complicated, though. I guess it would be enough to document
that you mustn't copy any extra files into pg_xlog if you use a fast
trigger.
Agreed. I added this note
On Tue, 2009-05-12 at 14:15 +0300, Heikki Linnakangas wrote:
Here's another idea: Let's modify xlog.c so that when the server asks
for WAL file X, and restore_command returns not found, the server
will not ask for any WAL files = X again (in that recovery session).
Presumably if X doesn't
Simon Riggs wrote:
On Tue, 2009-05-12 at 14:15 +0300, Heikki Linnakangas wrote:
Here's another idea: Let's modify xlog.c so that when the server asks
for WAL file X, and restore_command returns not found, the server
will not ask for any WAL files = X again (in that recovery session).
--On Mittwoch, Mai 06, 2009 19:04:21 -0400 Tom Lane t...@sss.pgh.pa.us
wrote:
So I'm now persuaded that a better textual representation for bytea
should indeed make things noticeably better here. It would be
useful though to cross-check this thought by profiling a case that
dumps a comparable
On Mon, May 11, 2009 at 11:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So I'm not seeing the point of risking unsafe behavior
in LOCK TABLE.
Me neither.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Khee Chin kheec...@gmail.com writes:
My sincere apologies for flooding your mailboxes once again, as the
patch attached in the previous post was incorrect. Also, I had failed
to show test-cases of \d index in both 8.4 and 8.3 servers.
This is still modifying the behavior of \di, which I
On Tue, 2009-05-12 at 14:38 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Tue, 2009-05-12 at 14:15 +0300, Heikki Linnakangas wrote:
Here's another idea: Let's modify xlog.c so that when the server asks
for WAL file X, and restore_command returns not found, the server
will
On Tue, 2009-05-12 at 16:43 +, Tom Lane wrote:
Fix LOCK TABLE to eliminate the race condition that could make it give weird
errors when tables are concurrently dropped. To do this we must take lock
on each relation before we check its privileges. The old code was trying
to do that the
Simon Riggs si...@2ndquadrant.com writes:
If we're going to require cascaded permissions like this, would it make
sense to make GRANT cascade down the inheritance tree also?
That's been discussed before. I forget whether we decided it was a good
idea or not, but in any case it looks like a
On Tue, 2009-05-12 at 17:10 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
If we're going to require cascaded permissions like this, would it make
sense to make GRANT cascade down the inheritance tree also?
That's been discussed before. I forget whether we decided it
Hello all!
If no one objecte (all agree, in other say) i continue work on patch -
particulary, i want support second strategy (tuple store instead of
hash-table) for save order of source (more cheap solution in case with
grouping sets + order by), investigate and brainstorm another
optimisation,
Bruce Momjian wrote:
Tom Lane wrote:
Erik Rijkers e...@xs4all.nl writes:
On Sun, May 10, 2009 02:05, Alvaro Herrera wrote:
I'm wondering that it could have forgotten to migrate the later table
segments ...
It seems al 'truncated' tables give
pg_relation_size(oid) = 1073741824
Erik Rijkers wrote:
One complication: I hadn't noticed
that there were 2 tables with a not yet
installed datatype. These tables were
simply not created by the pg_migrator-run.
I don't know how this influenced the results,
but I'll repeat it in the coming days.
I have modified pg_migrator
I've been poking at the problems described here:
http://archives.postgresql.org/message-id/20090306191404.gk3...@alvh.no-ip.org
http://archives.postgresql.org/message-id/5265.1240417...@sss.pgh.pa.us
I've about come to the conclusion that the only real fix is to abandon
our attempt to manage
On Tue, May 12, 2009 at 12:10, Alex Hunsaker bada...@gmail.com wrote:
On Mon, May 11, 2009 at 21:18, Tom Lane t...@sss.pgh.pa.us wrote:
However, he can do that anyway via ALTER TABLE, which
will happily take out AccessExclusiveLock before it checks any
permissions. So I'm not seeing the
Robert Haas wrote:
On Thu, Apr 30, 2009 at 8:36 AM, Peter Eisentraut pete...@gmx.net wrote:
The archives for this thread
http://archives.postgresql.org//pgsql-hackers/2009-04/threads.php#01329
show a bunch of missing messages. ?Were they being stored in a temporary
table?
On Tue, May 12, 2009 at 11:20:14PM +0200, Pavel Stehule wrote:
this patch has some bugs but it is good prototype (it's more stable
than old patch):
I'm not sure if you're at the point that you're interested in bug reports, but
here's something that didn't behave as expected:
5432 j...@josh*#
On Mar 27, 2009, at 2:36 AM, Simon Riggs wrote:
Not really. I want to understand the actual problem with
idle-in-transaction so we can consider all ways to solve it, rather
than
just focus on one method.
I have to distinct problems with idle in transaction. One is
reporting users / the
2009/5/13 Joshua Tolley eggyk...@gmail.com:
On Tue, May 12, 2009 at 11:20:14PM +0200, Pavel Stehule wrote:
this patch has some bugs but it is good prototype (it's more stable
than old patch):
I'm not sure if you're at the point that you're interested in bug reports, but
here's something that
20 matches
Mail list logo
