Joachim Wieland <[EMAIL PROTECTED]> writes:
> SET enable_bitmapscan = 0;
> EXPLAIN SELECT conname FROM pg_constraint WHERE conrelid =
> 'clstr_tst'::regclass;
> QUERY PLAN
> ---
> Seq
On Fri, May 25, 2007 at 12:09:43PM -0400, Tom Lane wrote:
> This is in the regression database after a completed regression run, so
> it's possible that it's a bit different state from what's seen at the
> instant the cluster test was running, but it sure looks like the
> "expected" results are wha
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Here's a new version, all known issues are now fixed. I'm now happy with
> this patch.
> Next, I'll start looking at the latest version of Jeff's synchronized
> scans patch.
I'm a bit confused --- weren't you intending to review these in parallel
Here's a new version, all known issues are now fixed. I'm now happy with
this patch.
Next, I'll start looking at the latest version of Jeff's synchronized
scans patch.
Bruce Momjian wrote:
Great. Based on this, do you have a patch that is ready to apply.
---
I wrote:
> Attached is a proposed replacement patch that keeps essentially all the
> advisor logic outside the core backend, and uses the method I suggested of
> modifying the result of get_relation_info() rather than installing phony
> system-catalog entries.
I've applied this with one further ch
Gregory Stark <[EMAIL PROTECTED]> writes:
> Perhaps this comes down to 64 vs 32 bit datum and aligments and therefore
> different size tables which because the planner does the lseek to measure the
> table size shows up as different estimates for sequential scan costs?
But we've got plenty of both
"Tom Lane" <[EMAIL PROTECTED]> writes:
> This is in the regression database after a completed regression run, so
> it's possible that it's a bit different state from what's seen at the
> instant the cluster test was running, but it sure looks like the
> "expected" results are what you get from a
Joachim Wieland <[EMAIL PROTECTED]> writes:
> EXPLAIN SELECT conname FROM pg_constraint WHERE conrelid =
> 'clstr_tst'::regclass;
> QUERY PLAN
> ---
> Index
Joachim Wieland <[EMAIL PROTECTED]> writes:
> As said before, it only happens with "make installcheck", not "make check".
Curious. I'm not sure if the buildfarm tries to isolate the
installation against its locale environment --- can you check the locale
used by the install case?
Joachim Wieland wrote:
> On Fri, May 25, 2007 at 10:33:41AM -0400, Tom Lane wrote:
> > We should find out why that's happening rather than just throwing an
> > ORDER BY at it. Considering the number of buildfarm machines that
> > aren't showing any such problem, there must be something odd about
>
On Fri, May 25, 2007 at 10:33:41AM -0400, Tom Lane wrote:
> We should find out why that's happening rather than just throwing an
> ORDER BY at it. Considering the number of buildfarm machines that
> aren't showing any such problem, there must be something odd about
> yours. What's the platform?
Joachim Wieland <[EMAIL PROTECTED]> writes:
> For some reason the cluster test fails on my machine due to a different
> order of the result rows when I run "installcheck" instead of "check". Is
> there a problem adding an ORDER BY to it?
We should find out why that's happening rather than just thr
The appended patch makes the msvc setting "integer_datetimes" propagate to
ecpg_config.h as well.
Joachim
Index: src/tools/msvc/Solution.pm
===
RCS file: /projects/cvsroot/pgsql/src/tools/msvc/Solution.pm,v
retrieving revision 1.25
d
For some reason the cluster test fails on my machine due to a different
order of the result rows when I run "installcheck" instead of "check". Is
there a problem adding an ORDER BY to it?
Joachim
Index: src/test/regress/sql/cluster.sql
=
14 matches
Mail list logo
