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 ha
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 pr
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 t
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
> Cc: Michael Gl
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
round
On Sat, 23 Jul 2005, Bruce Momjian wrote:
> Date: Sat, 23 Jul 2005 11:36:43 -0400 (EDT)
> From: Bruce Momjian
> To: ohp@pyrenet.fr
> Cc: Rocco Altier <[EMAIL PROTECTED]>,
> Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org,
> pgsql-hackers@postgresql.org
> Subject: Re
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 o
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 cl.relna
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.
> reg
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
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 b
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 rej
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 wa
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
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
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
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 worki
23 matches
Mail list logo
