On Fri, 2005-07-22 at 18:32 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
In summary, the CE feature will be a huge performance gain for
qualifying queries against large tables in PostgreSQL databases.
BTW, before we spend too much time chasing an emperor that may have no
Tom Lane wrote:
Could be. I went back to look at Sam Mason's report about three weeks
ago, and it definitely seems to explain his issue.
I've just built a patched version as well and it appears to be doing
what I think is the right thing now. I.e. actually picking the
plan with the lower cost.
Michael Fuhr wrote:
On Sat, Jul 23, 2005 at 11:18:57AM -0300, Tom Lane wrote:
In the stats test, delay for the stats collector to catch up using a
function that actually sleeps, instead of busy-waiting. Perhaps this
will resolve some of the intermittent stats failures we keep seeing.
Rocco Altier wrote:
This patch fixes the interval regression on my AIX box (kookaburra) by
only doing integer math on the interval, instead of float/double math.
I think this is the correct way to handle this, since it's an integer
data type.
I don't know if it will fix Olivier's problem,
This still does not fix the problem.
I had done my patch to try to mimic the way 8.0 had handled the math
with the remainders, but to carry it over another bucket (day).
The problem that I see is that we are taking day_remainder and
multiplying by USECS_PER_DAY. Which is a double * int64, thus
I just checked latest CVS (5 mn ago) the problem is still the same,
BTW, this is on Unixware 714 and no --enable-integer-datetime
Regards
On Sat, 23 Jul 2005, Rocco Altier wrote:
Date: Sat, 23 Jul 2005 11:15:44 -0400
From: Rocco Altier [EMAIL PROTECTED]
To: Bruce Momjian
ohp@pyrenet.fr wrote:
I just checked latest CVS (5 mn ago) the problem is still the same,
BTW, this is on Unixware 714 and no --enable-integer-datetime
Do you have the latest patch included int that version of CVS?
Anonymous CVS has a delay, and what was the problem you were seeing, the
On Sat, 23 Jul 2005, Bruce Momjian wrote:
Date: Sat, 23 Jul 2005 11:36:43 -0400 (EDT)
From: Bruce Momjian pgman@candle.pha.pa.us
To: ohp@pyrenet.fr
Cc: Rocco Altier [EMAIL PROTECTED],
Michael Glaesemann [EMAIL PROTECTED], pgsql-patches@postgresql.org,
pgsql-hackers@postgresql.org
Simon Riggs [EMAIL PROTECTED] writes:
It's very common to scan whole ranges of dates on a large table, so in
those cases you are really just maintaining the indexes for partitioning
purposes. On older data it may be desirable not to have lots of indexes,
or at least use their resources on the
I think the patch is ok now, intervall is not failing anymore as of
18:50 CET.
However stats fails.
regression.diffs:
*** ./expected/stats.outSat Jul 23 17:18:20 2005
--- ./results/stats.out Sat Jul 23 18:55:17 2005
***
*** 53,59
WHERE st.relname='tenk2' AND
Yes, we have seen those stat tests fail randomly. We are working on a
solution.
---
ohp@pyrenet.fr wrote:
I think the patch is ok now, intervall is not failing anymore as of
18:50 CET.
However stats fails.
Greg Stark [EMAIL PROTECTED] writes:
Note also that the index is only useful if the index is *being used*. And
index scans are much slower than sequential scans.
You miss my point entirely: an indexscan that hasn't got to retrieve any
rows (because it has a constraint that points off the end of
Tom Lane [EMAIL PROTECTED] writes:
And this decision is made separately for each child table, so the fact that
a seqscan might be the best bet for the target partition doesn't stop the
planner from using the indexscan in other partitions.
That was the detail I was missing. I'm surprised
This patch looks good. The only question I have is why you didn't want
the pgport rename/unlink calls? We usually use them unless there is
some reason not to.
---
Dave Page wrote:
[Resent as the list seems to have
FYI, I am seeing the same stats regression failures in CVS, even after
the recent commits to improve sleep().
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 23 July 2005 20:01
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] For review: Server instrumentation patch
This patch looks good. The only question I have is why you
didn't want
the
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 23 July 2005 20:01
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] For review: Server instrumentation patch
This patch looks good. The only question I have is
Greg Stark [EMAIL PROTECTED] writes:
That was the detail I was missing. I'm surprised because I actually tested
this before I sent the message and saw a plan like this with a single
sequential scan node despite the three child tables:
staging= explain select * from _test where a=1;
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, Jul 19, 2005 at 10:03:39AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Attached is a plpython_error_1.out file that will fix cuckoo.
What is the reason for the difference in the error
There is a bug in the in-memory bitmap index on the CVS Tip.
Consider this query: select * from bt1 where g=2 and e=20, which will generate
the following query plan:
QUERY PLAN
Jie Zhang [EMAIL PROTECTED] writes:
There is a bug in the in-memory bitmap index on the CVS Tip.
Good catch, thanks for the report.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Michael Fuhr [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm ... if it's *not* a version thing then I really do want to know
what's causing it. Anyone have an idea why this machine is saying
'\u80' where everyone else's python says u'\x80' ?
The regression tests that are failing are from the
On Sat, Jul 23, 2005 at 07:58:21PM -0400, Andrew Dunstan wrote:
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I don't think it's a version issue; cuckoo is at 2.4, platypus used to
be at 2.3 but I upgraded it to 2.4 to see if that was the issue, but
platypus kept working.
Hmm ...
23 matches
Mail list logo
