Tom Lane [EMAIL PROTECTED] writes:
The reason the patch is so short is that it's a kluge. If we really
cared about supporting this case, more wide-ranging changes would be
needed (eg, there's no need to eat maintenance_work_mem worth of RAM
for the dead-TIDs array); and a decent respect to
Bruce Momjian [EMAIL PROTECTED] wrote:
Is there anything to do for 8.2 here?
I'm working on Tom's idea. It is not a feature and does not change
the on-disk-structures, so I hope it meet the 8.2 deadline...
Tom Lane [EMAIL PROTECTED] wrote:
I'm wondering about doing something similar to what
Zdenek Kotala napsal(a):
Martijn van Oosterhout wrote:
On Wed, Aug 23, 2006 at 10:26:19AM +0200, Zdenek Kotala wrote:
5) Tuples
question: Does have data types some disk representation?
Does have tupleheader same structure?
I think only the inet/cidr types changed format
On Thu, Aug 24, 2006 at 09:40:13PM +0400, Teodor Sigaev wrote:
devel=# select 'blah foo bar'::tsvector = 'blah foo bar'::tsvector;
?column?
--
f
(1 row)
Fixed in 8.1 and HEAD. Thank you
Things still seem to be broken for me. Among other things, the script at
Adding -hackers back in...
-Original Message-
From: Chahine Hamila [mailto:[EMAIL PROTECTED]
Sent: Fri 8/25/2006 8:36 PM
To: Jim Nasby
Subject: Re: [HACKERS] integration of pgcluster into postgresql
First, you need to review all the past discussion
about the very
intentional decision
Hi,
Is there any reason for Rtree circle ops not being included in
PostgreSQL?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 6: explain analyze is your friend
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
The reason the patch is so short is that it's a kluge. If we really
cared about supporting this case, more wide-ranging changes would be
needed (eg, there's no need to eat maintenance_work_mem worth of RAM
for the dead-TIDs
To cut the Gordon knot I'm going to suggest we use:
\set CURSOR_FETCH fetch_count
and \g and ; are modified such that when they see
this variable set to fetch_count 0 and the buffer
is a select they would use the modified fetch/output code.
Does this sound reasonable to everyone?
OK
Tatsuo Ishii [EMAIL PROTECTED] writes:
Is there any reason for Rtree circle ops not being included in
PostgreSQL?
rtree is going away (has gone away in HEAD awhile ago, in fact).
regards, tom lane
---(end of broadcast)---
Andrew Dunstan wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I just detected another problem with building ecpg in a VPATH
environment. This patch fixes it for me.
Can't we get some of the buildfarm machines exercising VPATH?
This kinda stuff really ought to be
Tom,
So, I finally have new SpecJ tests, and between June 8th's 8.2 CVS and
last Wednesday's we're seeing a 10% drop in CPU utilization for a
fixed-size workload, which could mean that the buffer lock partitioning
resulted in less lock conflicts.
We'll see once we have the Dtrace reports
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I just detected another problem with building ecpg in a VPATH
environment. This patch fixes it for me.
Can't we get some of the buildfarm machines exercising VPATH?
This
Andrew Dunstan [EMAIL PROTECTED] writes:
Done. New machine is 'bustard'. But I couldn't get Alvaro's patch nor
Peter's suggestion to work :-( Maybe someone with more vpath-fu than me
can fix it.
I got it to build fairly easily, but the ecpg regression tests are a mess.
After some fooling
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Wait a minute. What I thought we had agreed to was a patch to make
commands sent with \g use a cursor. This patch changes SendQuery
so that *every* command executed via psql is treated this way.
That's what I remembered. I don't
[EMAIL PROTECTED] writes:
here comes the latest version (version 7) of the patch to handle large
result sets with psql. As previously discussed, a cursor is used
for SELECT queries when \set FETCH_COUNT some_value 0
Wait a minute. What I thought we had agreed to was a patch to make
commands
Tom Lane wrote:
Wait a minute. What I thought we had agreed to was a patch to make
commands sent with \g use a cursor. This patch changes SendQuery
so that *every* command executed via psql is treated this way.
That's what I remembered. I don't think we want to introduce a
difference
I think we shall have to reconsider that patch to turn it on by default.
So far I've seen two categories of failure:
* manual ANALYZE issued by regression tests fails because autovac is
analyzing the same table concurrently.
* contrib tests fail in their repeated drop/create database operations
Tom Lane wrote:
I think we shall have to reconsider that patch to turn it on by
default. So far I've seen two categories of failure:
So we turn autovacuum off for regression test instance.
* manual ANALYZE issued by regression tests fails because autovac is
analyzing the same table
Hi,
When persisting a holdable cursor at COMMIT time we currently choose to
rewind the executor and re-scan the whole result set into the tuplestore in
order to be able to scroll backwards later on. And then, we reposition the
cursor to the position we been in. However, unless I am missing
On Mon, 2006-08-28 at 13:45 -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Wait a minute. What I thought we had agreed to was a patch to make
commands sent with \g use a cursor. This patch changes SendQuery
so that *every* command executed via psql
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think we shall have to reconsider that patch to turn it on by
default. So far I've seen two categories of failure:
So we turn autovacuum off for regression test instance.
Not a solution for make installcheck, unless you are
Tom Lane wrote:
So we turn autovacuum off for regression test instance.
Not a solution for make installcheck,
Well, for make installcheck we don't have any control over whether
autovacuum has been turned on or off manually anyway. If you are
concerned about build farm reliability, the
I wrote:
BTW, it would sure be nice to know what happened here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=waspdt=2006-08-28%2017:05:01
LOG: autovacuum process (PID 26315) was terminated by signal 11
I was able to cause autovac to crash by repeating contrib/intarray
regression test
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ospreydt=2006-08-28%2016:00:17
shows another autovac-induced failure mode:
! psql: FATAL: sorry, too many clients already
initdb is choosing max_connections = 20 on this machine, which is
sufficient to run the parallel regression tests by
On Mon, Aug 28, 2006 at 12:16:40PM -0400, Tom Lane wrote:
122c122
#line 36 show.pgc
AFAICS there is no very good way to deal with this. I'd suggest
providing a way to suppress #line output from the ecpg preprocessor,
but perhaps there is another answer.
What about changing those lines
Phil Frost [EMAIL PROTECTED] writes:
Things still seem to be broken for me. Among other things, the script at
http://unununium.org/~indigo/testvectors.sql.bz2 fails. It performs two
tests, comparing 1000 random vectors with positions and random weights, and
comparing the same vectors, but
Performance-wise I took for granted without checking that GetVariable's
running time would be negligible.
[looks at the code]
I see it's it's basically two function calls with a loop over a linked
list of values (in the order of 10) doing strcmps and one strtol.
It is not quite clear to
On Mon, 2006-08-28 at 15:21 -0400, Tom Lane wrote:
We have more than enough problems to fix for 8.2 already. Let's
try to do this early in the 8.3 cycle instead.
I agree -- I think this is exactly the sort of change that is best made
at the beginning of a development cycle, so that there's a
Tatsuo Ishii [EMAIL PROTECTED] writes:
Is there any reason for Rtree circle ops not being included in
PostgreSQL?
rtree is going away (has gone away in HEAD awhile ago, in fact).
I know. I just want to make sure that there's any technical reason it
had not been supported for long time.
Chris Mair [EMAIL PROTECTED] writes:
The conclusion is that, yes, the overhead is measurable, albeit with
a very synthetic benchmark (of the type MySQL wins ;).
OK, so about 3 or 4% overhead added to extremely short queries.
That's not enough to kill this patch, but it's still annoying ...
and
Neil Conway wrote:
On Mon, 2006-08-28 at 15:21 -0400, Tom Lane wrote:
We have more than enough problems to fix for 8.2 already. Let's
try to do this early in the 8.3 cycle instead.
I agree -- I think this is exactly the sort of change that is best made
at the beginning of a development
Tatsuo Ishii [EMAIL PROTECTED] writes:
Tatsuo Ishii [EMAIL PROTECTED] writes:
Is there any reason for Rtree circle ops not being included in
PostgreSQL?
rtree is going away (has gone away in HEAD awhile ago, in fact).
I know. I just want to make sure that there's any technical reason it
The conclusion is that, yes, the overhead is measurable, albeit with
a very synthetic benchmark (of the type MySQL wins ;).
OK, so about 3 or 4% overhead added to extremely short queries.
More accurately, that 3 or 4% overhead is added to about all queries
(we're talking *psql*-only
Peter Eisentraut wrote:
Tom Lane wrote:
Not a solution for make installcheck,
Well, for make installcheck we don't have any control over whether
autovacuum has been turned on or off manually anyway. If you are
concerned about build farm reliability, the build farm scripts can
surely be
Peter Eisentraut wrote:
Tom Lane wrote:
Wait a minute. What I thought we had agreed to was a patch to make
commands sent with \g use a cursor. This patch changes SendQuery
so that *every* command executed via psql is treated this way.
That's what I remembered. I don't think we want to
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Tom Lane wrote:
Wait a minute. What I thought we had agreed to was a patch to make
commands sent with \g use a cursor.
I am confused. I assume \g and ; should be affected, like Peter says.
Tom, what *every* command are you
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Tom Lane wrote:
Wait a minute. What I thought we had agreed to was a patch to make
commands sent with \g use a cursor.
I am confused. I assume \g and ; should be affected, like Peter says.
Tom, what
Matthew T. O'Connor matthew@zeut.net writes:
Tom Lane wrote:
Not a solution for make installcheck,
I'm sure I'm missing some of the subtleties of make installcheck issues,
but autovacuum can be enabled / disabled on the fly just as easily as
stats_row_level, so I don't see the difference?
Bruce Momjian [EMAIL PROTECTED] writes:
OK, got it. I just don't see the value to doing \g and not ;. I think
the \gc case was a hack when he didn't have \set. Now that we have
\set, we should be consistent.
I'm willing to accept this if we can make sure we aren't adding any
overhead --- see
I am confused. I assume \g and ; should be affected, like Peter says.
Tom, what *every* command are you talking about? You mean \d?
Like I said, I thought we were intending to modify \g's behavior only;
that was certainly the implication of the discussion of \gc.
At some point
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, got it. I just don't see the value to doing \g and not ;. I think
the \gc case was a hack when he didn't have \set. Now that we have
\set, we should be consistent.
I'm willing to accept this if we can make sure we aren't
Tatsuo Ishii [EMAIL PROTECTED] writes:
Tatsuo Ishii [EMAIL PROTECTED] writes:
Is there any reason for Rtree circle ops not being included in
PostgreSQL?
rtree is going away (has gone away in HEAD awhile ago, in fact).
I know. I just want to make sure that there's any technical
Tatsuo Ishii wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
Tatsuo Ishii [EMAIL PROTECTED] writes:
Is there any reason for Rtree circle ops not being included in
PostgreSQL?
rtree is going away (has gone away in HEAD awhile ago, in fact).
I know. I just want to make sure
Alvaro Herrera [EMAIL PROTECTED] writes:
Tatsuo Ishii wrote:
Yes, probably the only way to help the user would be 1) build a new
pgfoundry or whatever open souce project 2) provide a commercial
support for him.
I wonder why isn't an option to migrate to GiST?
Indeed. The reason we removed
I just looked over the buildfarm results and was struck by the
observation that the stats regression test, which lately had been
failing once-in-a-while on Windows and never anywhere else, has a
batting average of 0-for-10-or-so over the past 24 hours on the Windows
buildfarm machines. I still
I wonder why isn't an option to migrate to GiST?
Indeed. The reason we removed rtree was that we could not see any case
where it was superior to GIST, and there were plenty of reasons why it
was inferior. What's the specific motivation for wanting to stay with
rtree?
Don't know. I just
46 matches
Mail list logo
