On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark [EMAIL PROTECTED] wrote:
I wonder if there's much of a use case for any statements aside from CREATE
statements. If we restrict it to CREATE statements we could hack things to
create pg_depend entries automatically. In which case we wouldn't need
On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan [EMAIL PROTECTED] wrote:
On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark [EMAIL PROTECTED] wrote:
I wonder if there's much of a use case for any statements aside from
CREATE
statements. If we restrict it to CREATE statements we could hack
Pavan Deolasee wrote:
On Fri, Apr 4, 2008 at 11:10 AM, Tom Lane [EMAIL PROTECTED] wrote:
The
policy of this project is that we only put nontrivial bug fixes into
back branches, and I don't think this item qualifies ...
Got it. I will submit a patch for HEAD.
Thanks,
As I
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I've been hacking on the idea of an Append node which maintains the ordering
of its subtables merging their records in order.
I finally got round to looking at this ...
A lot of things to chew on. Thanks very much.
Sorry to keep replying to myself, but part of the point of doing a
patch was to force myself (and whoever else is interested to examine
stuff that comes up...
On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan [EMAIL PROTECTED] wrote:
None of that suggests that an uninstaller script would be needed
Bruce Momjian [EMAIL PROTECTED] writes:
If the scanning of the inner side is a performance problem, why would we
be choosing a nested loop in the first place, vs. another type of join?
I clearly haven't done a good job explaining this as nobody seems to getting
what I'm describing. I think I'm
just started with 8.4 devel. Still focussing on LWlocks. With the
same load (#users benchmarktool) I now see LockID 11
(CLogControlLock) to be in the top waiting list.
This one was never noticable in 8.3.
Did anything change with respect to this?
Thanks
Paul
Tom Dunstan [EMAIL PROTECTED] writes:
OK, I found an example that does NOT fit the just drop all
dependencies scenario, but that I would still like to support. I just
had a look at the postgis pl/java support, and its install does stuff
like SELECT
Hello
when I tested ptop, I found some problems
this pgbench is very slow and when after getting table of locks from
ptop I got backend crash.
[EMAIL PROTECTED] ~]$ /usr/local/pgsql/bin/pgbench -c80 -t1000 postgres
starting vacuum...end.
WARNING: you don't own a lock of type ShareLock
WARNING:
On Mon, Apr 7, 2008 at 7:55 PM, Tom Lane [EMAIL PROTECTED] wrote:
Tom Dunstan [EMAIL PROTECTED] writes:
OK, I found an example that does NOT fit the just drop all
dependencies scenario, but that I would still like to support. I just
had a look at the postgis pl/java support, and its
Pavel Stehule wrote:
when I tested ptop, I found some problems
Which version are you running?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 07/04/2008, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Pavel Stehule wrote:
when I tested ptop, I found some problems
Which version are you running?
I am sorry, HEAD 8.4 today actualized
Pavel
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via
Pavel Stehule escribió:
WARNING: problem in alloc set MessageContext: req size alloc size
for chunk 0x8b6d1e0 in block 0x8b6bb50
WARNING: problem in alloc set MessageContext: req size alloc size
for chunk 0x8b6d1e0 in block 0x8b6bb50
I suggest you make distclean and rebuild the whole
On 07/04/2008, Alvaro Herrera [EMAIL PROTECTED] wrote:
Pavel Stehule escribió:
WARNING: problem in alloc set MessageContext: req size alloc size
for chunk 0x8b6d1e0 in block 0x8b6bb50
WARNING: problem in alloc set MessageContext: req size alloc size
for chunk 0x8b6d1e0 in block
We are down to 12 feature freeze items (240 emails):
http://momjian.us/cgi-bin/pgpatches
Most are not ready to apply but require feedback to the author.
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://enterprisedb.com
On Mar 27, 2008, at 10:47 AM, Aidan Van Dyk wrote:
I was recently made aware of this:
http://repo.or.cz/w/PostgreSQL.git?
a=commit;h=69db64c737012a8d2d6fbcce3ace7136cb2bc85f
I started digging around to figure this out on Tuesday.
It appears as if the rsync mirror of CVS is not always good.
Bruce,
We are down to 12 feature freeze items (240 emails):
http://momjian.us/cgi-bin/pgpatches
Most are not ready to apply but require feedback to the author.
Yaaay!
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the tools?
On Apr 1, 2008, at 10:03 PM, Greg Smith wrote:
The idea we were bouncing around went a step past that and
considered this: if you have good statistics on a table, and you
have a sample set of queries you want to execute against it, how
would you use that information to plan what indexes
On Apr 1, 2008, at 7:20 PM, Stephen Frost wrote:
* Greg Smith ([EMAIL PROTECTED]) wrote:
=4 cores, =8GB RAM, and =8 disks with a usable write-caching
controller
in it.
hrmmm. So a DL385G2, dual-proc/dual-core with 16GB of ram and 8 SAS
disks with a Smart Array P800 w/ 512MB of write cache
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
--
Decibel!, aka Jim C. Nasby, Database
Josh Berkus wrote:
Bruce,
We are down to 12 feature freeze items (240 emails):
http://momjian.us/cgi-bin/pgpatches
Most are not ready to apply but require feedback to the author.
Yaaay!
Maybe we should make the next commit-fest June 1 to give people some time
off? And
On Mon, 7 Apr 2008 14:31:51 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Maybe we should make the next commit-fest June 1 to give people
some time off? And some time to improve the tools?
Agreed.
+1
Joshua D. Drake
--
The PostgreSQL Company since 1997:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the tools?
I would rather do the commit fests often, to keep the patch queue and
the commit fests short.
--
Heikki Linnakangas
EnterpriseDB
On Apr 3, 2008, at 4:51 PM, Andrew Dunstan wrote:
Several years ago Bruce and I discussed the then theoretical use of
a SELECT query as the source for COPY TO, and we agreed that the
sane analog would be to have an INSERT query as the target of COPY
FROM.
This idea seems to take that
Right now it isn't possible to use file system snapshots a reliable
backup if you are using multiple file systems for tablespaces because
most systems don't allow the simultaneous snapshoting of multiple file
system. Our documentation mentions this:
If your database is spread across
On Apr 3, 2008, at 9:35 AM, Tom Lane wrote:
Dawid Kuroczko [EMAIL PROTECTED] writes:
The idea of \G command is to perform the query, but with printing
query results using extended table output format.
Seems a bit useless --- if you prefer \x format, wouldn't you
prefer it
all the time? Or
Bruce Momjian wrote:
Right now it isn't possible to use file system snapshots a reliable
backup if you are using multiple file systems for tablespaces because
most systems don't allow the simultaneous snapshoting of multiple file
system. Our documentation mentions this:
If your
On Mon, Apr 7, 2008 at 2:58 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Incidentally, I looked at this stuff just a couple of days ago, and it
occurred to me that we really should make it easier to take a hot backup
with that mechanism. We shouldn't require setting up archive_command, and
Decibel! wrote:
On Apr 3, 2008, at 4:51 PM, Andrew Dunstan wrote:
Several years ago Bruce and I discussed the then theoretical use of a
SELECT query as the source for COPY TO, and we agreed that the sane
analog would be to have an INSERT query as the target of COPY FROM.
This idea seems to
Heikki Linnakangas wrote:
However, it occurred to me that if someone turned on continuous arciving
during the file system snapshots, then you could use PITR to recover
from file system snapshots that were not simultaneous.
Should this be documented?
If you use continuous archiving,
Le Monday 07 April 2008 21:04:26 Andrew Dunstan, vous avez écrit :
Quite apart from any other reason why not, this would be a horrid hack
and is just the sort of feature we rightly eschew, IMNSHO. COPY is
designed as a bulk load/unload facility. It's fragile enough in that role.
And my main
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
There's the START WITH option for
[EMAIL PROTECTED] (Heikki Linnakangas) writes:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some
time off? And some time to improve the tools?
I would rather do the commit fests often, to keep the patch queue and
the commit fests short.
But if it means
Chris Browne wrote:
[EMAIL PROTECTED] (Heikki Linnakangas) writes:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some
time off? And some time to improve the tools?
I would rather do the commit fests often, to keep the patch queue and
the
On Sun, Apr 06, 2008 at 11:29:50PM +0100, Gregory Stark wrote:
I wonder if there's much of a use case for any statements aside from
CREATE statements.
Yes. Some modules could have COPY or equivalent in them, as they
could easily contain data.
Cheers,
David.
--
David Fetter [EMAIL PROTECTED]
FYI, we (Stefan and I) started a wiki page to organize this effort:
http://wiki.postgresql.org/wiki/Performances_QA_testing . Ideas and
participation are very welcome.
I also described the platform we have here and the usage of each
server:
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Applied to HEAD.
At this point it would probably be a good idea if a couple of buildfarm
machines were to start testing builds with --disable-integer-datetimes
... any volunteers out there?
I have changed the
Heikki Linnakangas [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the tools?
I would rather do the commit fests often, to keep the patch queue and the
commit fests short.
Just throwing
Bruce Momjian [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the tools?
Agreed.
I don't agree, not even a little bit. The reason this fest has been so
long and painful is that the queue
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the tools?
Agreed.
I don't agree, not even a little bit. The reason this fest has been so
long and
Gregory Stark [EMAIL PROTECTED] writes:
Just throwing out a crazy idea. What if we had a commitfest as scheduled at
the start of May but made it a Tom-free commitfest. Specifically to try to
organize a larger work-force rather than to leave it all on Tom's shoulders.
Not that your efforts
Dimitri Fontaine [EMAIL PROTECTED] writes:
And my main concern would still be left as-is, COPY wouldn't have any
facility
to cope with data representation not matching what datatype input functions
want to read.
That's sufficiently covered by the proposal to allow a COPY FROM as a
table
Paul van den Bogaard [EMAIL PROTECTED] writes:
just started with 8.4 devel. Still focussing on LWlocks. With the
same load (#users benchmarktool) I now see LockID 11
(CLogControlLock) to be in the top waiting list.
This one was never noticable in 8.3.
Did anything change with respect
[EMAIL PROTECTED] (Peter Eisentraut) writes:
Implement a few changes to how shared libraries and dynamically loadable
modules are built.
Seems this patch has broken all the Windows buildfarm animals ... is
anybody on that?
regards, tom lane
--
Sent via pgsql-hackers
On Mon, 7 Apr 2008 22:05:09 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Better tools would be good, but unless someone commits to producing
a tool that will be ready by June but not by May, that's not a good
reason to slide either.
Fine with me --- I just wanted to give Tom a
Tom Lane wrote:
[EMAIL PROTECTED] (Peter Eisentraut) writes:
Implement a few changes to how shared libraries and dynamically loadable
modules are built.
Seems this patch has broken all the Windows buildfarm animals ... is
anybody on that?
Not all, only those that use the
46 matches
Mail list logo
