Zoltan Boszormenyi írta:
The option parsing and error checking is now common.
I also changed it to use transformStmt() in analyze.c.
However, both the UNION and sunselect cases give me
something like this:
ERROR: could not open relation 1663/16384/16723: No such file or
directory
What else
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
The option parsing and error checking is now common.
I also changed it to use transformStmt() in analyze.c.
However, both the UNION and sunselect cases give me
something like this:
ERROR: could not open relation 1663/16384/16723: No such file
--On Donnerstag, August 24, 2006 11:02:43 -0500 Jaime Casanova
[EMAIL PROTECTED] wrote:
Actually the code delete implicit rules based on a field added to
pg_rewrite but that catalog has a unique index on ev_class, rulename:
pg_rewrite_rel_rulename_index UNIQUE, btree (ev_class, rulename)
i
Hi,
Robert Treat [EMAIL PROTECTED] writes:
On Tuesday 22 August 2006 16:10, Tom Lane wrote:
As I see it, we've effectively got a patch that was rejected once,
and Bruce wants to apply it anyway because no replacement has been
forthcoming.
Well, unless someone is going to commit to doing it
--On Dienstag, August 22, 2006 23:12:21 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of
On Tue, Aug 22, 2006 at 01:11:22PM -0400, Andrew Dunstan wrote:
There's nothing hidden (unless it's also hidden from me ;-) )
I take it that when you talk about we did this you are referring to
the patch from Karel Zak.
Hans has been original author of COPY VIEW idea and I've wrote it for
Hi all,
seriously... I don't have time to work on PostgreSQL. It's time to
say that I'm leaving this project. So, if you found some my broken
code or whatever in PostgreSQL you should go and fix it. It's
community-driven project. It's about collaboration -- don't ask why
should I help --
Patch isn't full, simple test (values are took from regression.diffs):
and try dump table and restore:
ERROR: syntax error
CONTEXT: COPY tt, line 5, column tq: '1 ''2'
Attached cumulative patch fixes problem, but I have some doubts, is it really
needed?
--
Teodor Sigaev
Tom Lane wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of those
others. But is that what I should be spending my time on in the
Bernd Helmle [EMAIL PROTECTED] writes:
What are these open issues for the updatable views patch you are seeing
exactly?
Didn't Alvaro list a bunch of issues when he put the patch back up for
comment? I have not looked at it myself yet.
i see the INSERT...RETURNING stuff as the only big hurd
--On Mittwoch, August 23, 2006 08:24:55 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
What are these open issues for the updatable views patch you are seeing
exactly?
Didn't Alvaro list a bunch of issues when he put the patch back up for
comment? I have not looked at it myself yet.
Indeed he
Hi,
Tom Lane wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of those
others. But is that what I should be spending my time on
Böszörményi Zoltán wrote:
Hi,
Tom Lane wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of those
others. But is that what
Böszörményi Zoltán wrote:
Hi,
Tom Lane wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of
those
others. But is that what I
Böszörményi Zoltán wrote:
So when will you send in a revised patch?
Soon. :-)
No, don't send it soon. We're in feature freeze already (and have
been for three weeks). You need to send it now.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
Böszörményi Zoltán wrote:
So when will you send in a revised patch?
Soon. :-)
No, don't send it soon. We're in feature freeze already (and have
been for three weeks). You need to send it now.
I have to test it some more but I will send it.
Best regards,
Zoltán Böszörményi
B?sz?rm?nyi Zolt?n wrote:
B?sz?rm?nyi Zolt?n wrote:
So when will you send in a revised patch?
Soon. :-)
No, don't send it soon. We're in feature freeze already (and have
been for three weeks). You need to send it now.
I have to test it some more but I will send it.
I think
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said now, but I don't think we need it immediately,
especially if he is still
Böszörményi Zoltán wrote:
B?sz?rm?nyi Zolt?n wrote:
So when will you send in a revised patch?
Soon. :-)
No, don't send it soon. We're in feature freeze already (and have
been for three weeks). You need to send it now.
I have to test it some more but I will send it.
I think
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
cheers
andrew
---(end of broadcast)---
TIP 6: explain analyze is your friend
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said now, but I don't think we need it immediately,
especially if he is still working on it. We are at least 1-2 weeks away
from
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said now, but I don't think we need it immediately,
especially if he is still working on it. We are at least
Hi,
Bruce Momjian írta:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said now, but I don't
Zoltan Boszormenyi írta:
Hi,
Bruce Momjian írta:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said
Zoltan Boszormenyi wrote:
OK, here's my current version. The reference leak is fixed.
But as my testcase shows, it only works for single selects
currently. The parser accepts it but COPY doesn't produce
the expected output. Please, suggest a solution.
I'm not sure I agree with the approach
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
OK, here's my current version. The reference leak is fixed.
But as my testcase shows, it only works for single selects
currently. The parser accepts it but COPY doesn't produce
the expected output. Please, suggest a solution.
I'm not
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, based on this feedback, I am adding COPY VIEW to the patches queue.
I think we have other things that demand our attention more than a
half-baked feature.
Well, the patch was submitted in time, and it is a
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Well, the patch was submitted in time, and it is a desired feature. If
we want to hold it for 8.3 due to lack of time, we can, but I don't
think we can decide now that it must wait.
well I thought the agreed approach to
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, based on this feedback, I am adding COPY VIEW to the patches queue.
I think we have other things that demand our attention more than a
half-baked feature.
Andrew Dunstan [EMAIL PROTECTED] writes:
It's a close call. On balance I'd be inclined to accept the patch if it
reviews OK, even though we will throw the code away soon (we hope).
Well, the patch seems pretty ugly code-wise as well. I'd be willing to
clean it up if I thought it wouldn't
Hans-Juergen Schoenig wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Well, the patch was submitted in time, and it is a desired
feature. If
we want to hold it for 8.3 due to lack of time, we can, but I don't
think we can decide now that it
Hans-Juergen Schoenig wrote:
It has been made as COPY FROM / TO view because people wanted it to be
done that way.
My original proposal was in favour of arbitrary SELECTs (just like
proposed by the TODO list) but this was rejected. So, we did it that way
(had to explain to customer why
Alvaro Herrera [EMAIL PROTECTED] writes:
It sucks that patches are posted and no action is taken on them for
months. I agree with that.
This particular patch was originally posted during the 8.1 feature
freeze window (2005-09-29), so it was doomed to a certain amount of
languishing on the
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
It sucks that patches are posted and no action is taken on them for
months. I agree with that.
This particular patch was originally posted during the 8.1 feature
freeze window (2005-09-29), so it was doomed to a certain amount of
On Tuesday 22 August 2006 16:10, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
It sucks that patches are posted and no action is taken on them for
months. I agree with that.
This particular patch was originally posted during the 8.1 feature
freeze window (2005-09-29), so it was
Robert Treat [EMAIL PROTECTED] writes:
On Tuesday 22 August 2006 16:10, Tom Lane wrote:
As I see it, we've effectively got a patch that was rejected once,
and Bruce wants to apply it anyway because no replacement has been
forthcoming.
Well, unless someone is going to commit to doing it the
Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On Tuesday 22 August 2006 16:10, Tom Lane wrote:
As I see it, we've effectively got a patch that was rejected once,
and Bruce wants to apply it anyway because no replacement has been
forthcoming.
Well, unless someone is going to
On 8/21/06, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
(I wouldn't do it like this though --- TransactionIdAdvance itself is
the place to bump the secondary counter.)
Agreed.
I reconsidered after trying to do it that way --- although fixing
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The part of this that would actually be useful to put in core is
maintaining a 64-bit XID counter, ie, keep an additional counter that
bumps every time XID wraps around. This cannot be done very well from
outside core but it would be
Am Donnerstag, 17. August 2006 20:05 schrieb Chris Mair:
\gc sounds like a good idea to me :)
Strictly speaking, in the randomly defined grammer of psql, \gc is \g with an
argument of 'c' (try it, it works).
I'm not sure what use case you envision for this feature. Obviously, this is
for
Tom Lane wrote:
BTW, \u seems not to have any mnemonic value whatsoever ... isn't
there some other name we could use?
Ever since pgsql-patches replies started going to -hackers, threading
doesn't work anymore, so I for one can't tell what this refers to at
all.
--
Peter Eisentraut
Peter Eisentraut wrote:
Tom Lane wrote:
BTW, \u seems not to have any mnemonic value whatsoever ... isn't
there some other name we could use?
Ever since pgsql-patches replies started going to -hackers, threading
doesn't work anymore, so I for one can't tell what this refers to at
all.
On Thu, 2006-08-17 at 03:14 -0400, Bruce Momjian wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
BTW, \u seems not to have any mnemonic value whatsoever ... isn't
there some other name we could use?
Ever since pgsql-patches replies started going to -hackers, threading
doesn't work
Chris Mair wrote:
At some point we ought to extend libpq enough to expose the V3-protocol
feature that allows partial fetches from portals; that would be a
cleaner way to implement this feature. However since nobody has yet
proposed a good API for this in libpq, I don't object to
Replying to myself...
Patch with fix against current CVS is attached.
Alvaro Herrera sent two fixes off-list: a typo and
at the end of SendQueryUsingCursor I sould COMMIT, not ROLLBACK.
So, one more version (6) that fixes these too is attached.
Bye, Chris.
PS: I'm keeping this on both lists
Patch with fix against current CVS is attached.
Forgot the attachment... soory.
--
Chris Mair
http://www.1006.org
diff -rc pgsql.original/doc/src/sgml/ref/psql-ref.sgml pgsql/doc/src/sgml/ref/psql-ref.sgml
*** pgsql.original/doc/src/sgml/ref/psql-ref.sgml 2006-08-17 16:50:58.0
BTW, \u seems not to have any mnemonic value whatsoever ... isn't there
some other name we could use?
True :)
Since buffer commands all have a single char I wanted a single char one
too. The c for cursor was taken already, so i choose the u (second
char in cursor). If somebody
Chris Mair wrote:
BTW, \u seems not to have any mnemonic value whatsoever ... isn't there
some other name we could use?
True :)
Since buffer commands all have a single char I wanted a single char one
too. The c for cursor was taken already, so i choose the u (second
char
Bruce Momjian [EMAIL PROTECTED] writes:
Chris Mair wrote:
Since buffer commands all have a single char I wanted a single char one
too. The c for cursor was taken already, so i choose the u (second
char in cursor). If somebody has a better suggestion, let us know ;)
I think a new backslash
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Chris Mair wrote:
Since buffer commands all have a single char I wanted a single char one
too. The c for cursor was taken already, so i choose the u (second
char in cursor). If somebody has a better suggestion, let us know ;)
I
Since buffer commands all have a single char I wanted a single char one
too. The c for cursor was taken already, so i choose the u (second
char in cursor). If somebody has a better suggestion, let us know ;)
I think a new backslash variable isn't the way to go. I would use a
On Tue, 2006-08-15 at 18:42 -0400, Tom Lane wrote:
I wrote:
It'd definitely be nicer that way, but given the current limitations of
bootstrap mode I see no non-kluge way to make a built-in function have
OUT parameters. (Hint: array_in doesn't work in bootstrap mode.)
Actually, that
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2006-08-15 at 18:42 -0400, Tom Lane wrote:
So let's fix pg_xlogfile_name_offset() to have two OUT parameters
instead of returning a smushed-together string.
I'll do this, but I'm conscious that this is a cosmetic change.
Well, it's cosmetic, but
Simon Riggs [EMAIL PROTECTED] writes:
We want a single row output, with two columns, yes?
Presumably:
xlogfilenameTEXT
offset INTEGER
Sounds right to me. int4 should be wide enough for practical xlog
segment sizes.
regards, tom lane
On Wed, 2006-08-16 at 08:51 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2006-08-15 at 18:42 -0400, Tom Lane wrote:
So let's fix pg_xlogfile_name_offset() to have two OUT parameters
instead of returning a smushed-together string.
I'll do this, but I'm conscious
On Wed, 2006-08-16 at 11:45 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We want a single row output, with two columns, yes?
Presumably:
xlogfilenameTEXT
offset INTEGER
Sounds right to me. int4 should be wide enough for practical xlog
segment
Simon Riggs [EMAIL PROTECTED] writes:
but my initdb fails with
creating template1 database in a/base/1 ... FATAL: cache lookup failed
for type 26
Um ... when did you last cvs update? That was the behavior up till I
fixed array_in for bootstrap mode, yesterday afternoon ...
On Wed, 2006-08-16 at 16:51 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
but my initdb fails with
creating template1 database in a/base/1 ... FATAL: cache lookup failed
for type 26
Um ... when did you last cvs update? That was the behavior up till I
fixed array_in
Simon Riggs [EMAIL PROTECTED] writes:
Wise one: what should my pg_proc look like?
DATA(insert OID = 2850 ( pg_xlogfile_name_offset PGNSP PGUID 12 f f t f
i 1 2249 25 25 25 23 i o o _null_ pg_xlogfile_name_offset -
_null_ ));
Oh, as far as that goes, the array columns need to look like
On Wed, 2006-08-16 at 17:09 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Wise one: what should my pg_proc look like?
DATA(insert OID = 2850 ( pg_xlogfile_name_offsetPGNSP PGUID 12 f f t f
i 1 2249 25 25 25 23 i o o _null_ pg_xlogfile_name_offset -
_null_ ));
Oh,
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
In the case of a heavily update workload, the default naptime (60 seconds)
is too long to keep the number of dead tuples low. With my patch, the naptime
will be adjusted around 3 seconds at the case of pgbench (scale=10, 80 tps)
with default other
On Tue, Aug 15, 2006 at 06:07:12PM +0100, Simon Riggs wrote:
On Tue, 2006-08-15 at 11:10 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
postgres=# select pg_xlogfile_name_offset(pg_switch_xlog());
pg_xlogfile_name_offset
---
On Tue, 2006-08-15 at 12:13 -0500, Jim C. Nasby wrote:
On Tue, Aug 15, 2006 at 06:07:12PM +0100, Simon Riggs wrote:
On Tue, 2006-08-15 at 11:10 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
postgres=# select pg_xlogfile_name_offset(pg_switch_xlog());
Jim C. Nasby [EMAIL PROTECTED] writes:
True, but making people parse the output of a function to seperate the
two fields seems pretty silly. Is there some reason why
pg_xlogfile_name_offset shouldn't be a SRF, or use two out parameters?
It'd definitely be nicer that way, but given the current
I wrote:
It'd definitely be nicer that way, but given the current limitations of
bootstrap mode I see no non-kluge way to make a built-in function have
OUT parameters. (Hint: array_in doesn't work in bootstrap mode.)
Actually, that turns out not to be so hard to fix as I thought.
array_in
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
This issue is closed, right?
We've agreed we need two functions, but it's not done yet. Seems pretty
trivial though ...
OK, that's what I was unclear about.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDB
David Fetter wrote:
On Sat, Jul 29, 2006 at 09:14:16PM -0400, Greg Sabino Mullane wrote:
Today on IRC David Fetter and some others were discussing version
numbers and we realized that although libpq now provides the version
of Postgres as a number, this is still a wheel that is being
On Aug 10, 2006, at 7:57 AM, Tom Lane wrote:
Anyway, after further thought I've concluded that we really should
supply something that returns the Insert pointer, as this would be
useful for debugging and system-monitoring purposes. It's clear
however
that we also need something that returns
Gene [EMAIL PROTECTED] writes:
Your best bet might be to partition the table into two subtables, one
with stable data and one with the fresh data, and transfer rows from
one to the other once they get stable. Storage density in the fresh
part would be poor, but it should be small enough you
On Mon, 2006-08-07 at 13:05 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I've implemented this for BTree, GIN, GIST using an additional rmgr
functionbool rm_safe_restartpoint(void)
...
Recovery checkpoints are now renamed restartpoints to avoid
confusion with
Am Freitag, 4. August 2006 04:50 schrieb Tom Lane:
I'd like to see us refactor the docs as necessary to reflect that idea.
Peter is right that this needs some discussion in syntax.sgml as well as
in the reference pages --- but I'm still not very clear on how the
presentation should go.
I'm
On Wed, Aug 09, 2006 at 03:05:02PM +0200, Peter Eisentraut wrote:
Am Freitag, 4. August 2006 04:50 schrieb Tom Lane:
I'd like to see us refactor the docs as necessary to reflect that
idea. Peter is right that this needs some discussion in
syntax.sgml as well as in the reference pages ---
David Fetter [EMAIL PROTECTED] writes:
However, there are some oddities:
postgres=# SELECT * FROM (VALUES (1,2)) AS foo(bar,baz);
[ works ]
postgres=# (VALUES (1,2)) AS foo(bar,baz);
ERROR: syntax error at or near AS
This is per spec. Effectively, AS is part of the FROM-clause syntax
not
OK, done.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Seems like this probably ought to round up not down:
I thought about that, but because statement_timeout is in millis, and
not
I have a table that inserts lots of rows (million+ per day) int8 as primary key, and I cluster by a timestamp which is approximately the timestamp of the insert beforehand and is therefore in increasing order and doesn't change. Most of the rows are updated about 3 times over time roughly within
Have we made a decision on this issue? Should I apply my patch that
still forces a split unless 10% of the page has been freed?
---
Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
This is a revised patch
Bruce Momjian [EMAIL PROTECTED] writes:
Have we made a decision on this issue? Should I apply my patch that
still forces a split unless 10% of the page has been freed?
I haven't gotten back to doing any more performance testing. Please
stick that patch on the pending queue, so we don't forget
Gene [EMAIL PROTECTED] writes:
I have a table that inserts lots of rows (million+ per day) int8 as primary
key, and I cluster by a timestamp which is approximately the timestamp of
the insert beforehand and is therefore in increasing order and doesn't
change. Most of the rows are updated about
You are correct the main part I'm worried about is the updates, being so far from the originals. fyi I
am partitioning the tables by the timestamp column,vacuum analyzing once per hour, creating one child
partition per day in a cron job. Because I'm using hibernate for database abstraction
Simon Riggs [EMAIL PROTECTED] writes:
I've implemented this for BTree, GIN, GIST using an additional rmgr
function bool rm_safe_restartpoint(void)
...
Recovery checkpoints are now renamed restartpoints to avoid
confusion with checkpoints. So checkpoints occur during normal
processing
Applied. Changes are:
For protocol-level prepare/bind/execute:
o print user name for all
o print portal name if defined for all
o print query for all
o reduce log_statement header to single keyword
o print bind parameters as DETAIL if text
Bruce Momjian wrote:
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
A 50-parameter query could be .. interesting ..
I realize that you need this level of output to reflect what is
happening at the protocol level, but seeing all the protocol detail is
not really what
Sorry, forgot to show sample output:
LOG: prepare sel1: SELECT $1 + $2;
LOG: bind sel1: SELECT $1 + $2;
DETAIL: $1 = 8, $2 = 5
LOG: execute sel1: SELECT $1 + $2;
LOG: prepare sel1: SELECT 3;
LOG: bind sel1: SELECT 3;
On Sat, Aug 05, 2006 at 07:39:48PM +1200, Oliver Jowett wrote:
Bruce Momjian wrote:
OK, updated patch, with output of text bind parameters. New output
is:
LOG: prepare sel1: SELECT $1 + $2;
LOG: bind sel1: SELECT $1 + $2;
LOG: bind sel1: parameter 1: 8
Oliver Jowett [EMAIL PROTECTED] writes:
A 50-parameter query could be .. interesting ..
I realize that you need this level of output to reflect what is
happening at the protocol level, but seeing all the protocol detail is
not really what you expect when you turn on basic statement logging,
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
A 50-parameter query could be .. interesting ..
I realize that you need this level of output to reflect what is
happening at the protocol level, but seeing all the protocol detail is
not really what you expect when you turn on
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I modified the code to store the user statement name in the portal for
protocol execute, so I can print the user name at that time.
Please forget that and print the portal name. I'm getting tired of
repeating it, but: there are two
Albe Laurenz wrote:
Tim Allen wrote:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch
Joshua D. Drake wrote:
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
Why not?
It might be interesting to have some links in the external projects area
for replication, but a section of its own doesn't seem relevant.
I disagree about having some
Alvaro Herrera wrote:
Joshua D. Drake wrote:
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
Why not?
Well Peter said that, not me :)
It might be interesting to have some links in the external projects area
for replication, but a section of its
Joshua D. Drake wrote:
Alvaro Herrera wrote:
Joshua D. Drake wrote:
I don't think this sort of material belongs directly into the PostgreSQL
documentation.
Why not?
Well Peter said that, not me :)
I know, but I though I'd post one message instead of two. (In fact I
didn't even think
On Sun, Jul 30, 2006 at 08:38:30PM -0400, Rod Taylor wrote:
On Sun, 2006-07-30 at 20:20 -0400, Robert Treat wrote:
On Thursday 27 July 2006 09:28, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
UPDATE mytab SET (foo, bar, baz) =
Nice. I was going to ask if this could make it into 8.2.
---
Simon Riggs wrote:
On Sun, 2006-07-16 at 20:56 +0100, Simon Riggs wrote:
On Sun, 2006-07-16 at 15:33 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED]
On Thursday 27 July 2006 09:28, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
UPDATE mytab SET (foo, bar, baz) =
(SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
That UPDATE example is interesting because I remember
On Sun, 2006-07-30 at 20:20 -0400, Robert Treat wrote:
On Thursday 27 July 2006 09:28, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
UPDATE mytab SET (foo, bar, baz) =
(SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
Are we done with the sort interrupt issue mentioned in the subject line,
and the issue outlined below?
---
Tom Lane wrote:
Charles Duffy [EMAIL PROTECTED] writes:
... For the 'long' data, the compare moves on rightward
Bruce Momjian [EMAIL PROTECTED] writes:
Are we done with the sort interrupt issue mentioned in the subject line,
and the issue outlined below?
I'm inclined not to apply the proposed patch (adding
CHECK_FOR_INTERRUPTS) because of the risk of memory leakage inside
qsort. OTOH you could argue
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Are we done with the sort interrupt issue mentioned in the subject line,
and the issue outlined below?
I'm inclined not to apply the proposed patch (adding
CHECK_FOR_INTERRUPTS) because of the risk of memory leakage inside
qsort.
On 7/15/06, Tom Lane [EMAIL PROTECTED] wrote:
Anyway, Qingqing's question still needs to be answered: how can a sort
of under 30k items take so long?
It happens because (as previously suggested by Tom) the dataset for
the 'short' (~10k rows, .3 sec) sort has no rows whose leftmost fields
Charles Duffy [EMAIL PROTECTED] writes:
... For the 'long' data, the compare moves on rightward until it
encounters 'flato', which is a TEXT column with an average length of
7.5k characters (with some rows up to 400k). The first 6 columns are
mostly INTEGER, so compares on them are relatively
401 - 500 of 660 matches
Mail list logo
