"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Wed, 2007-07-25 at 22:20 +0100, Gregory Stark wrote:
>> Also, it might let us set up a standby database in the regression
>> suite which would give us some xlog coverage as well which is a
>> critical portion of the system the regression suite doesn't
On Wed, 2007-07-25 at 22:20 +0100, Gregory Stark wrote:
> Also, it might let us set up a standby database in the regression
> suite which would give us some xlog coverage as well which is a
> critical portion of the system the regression suite doesn't test at
> all.
I like that general thought and
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
Someday we might like to allow this, but it seems to mean inventing a
new GUC context type, which I don't think I want to get into right now.
Another option would be adding an option to initdb to override default config
set
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Someday we might like to allow this, but it seems to mean inventing a
> new GUC context type, which I don't think I want to get into right now.
Another option would be adding an option to initdb to override default config
settings in the postgreql.conf. Th
I wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Maybe what we could do is set higher thresholds for the regression
>> database with ALTER DATABASE.
> That seems to make sense at least as a short-term response.
I tried this, and it crashed and burned:
ERROR: parameter "autovacuum_analyz
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> While I don't have any very strong objection to putting an ORDER BY
>> on these particular queries, I'm worried about how many other regression
>> tests will now start showing random failures. We have an awful lot
>> of small tables i
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>> Gregory Stark wrote:
What really has to happen is it should run analyze on all tables
together in a single transaction and commit all the new stats together
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Gregory Stark wrote:
>>> What really has to happen is it should run analyze on all tables
>>> together in a single transaction and commit all the new stats together.
>>> Out-of-sync stats can be worse than out-o
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What I don't understand is what you mean with it "obliterating" the
> stats for a table.
The point seems to be that if there is no pg_statistic data for these
tables, we fall back to default estimates of the selectivity of the
WHERE clauses, and those p
Tom Lane wrote:
> While I don't have any very strong objection to putting an ORDER BY
> on these particular queries, I'm worried about how many other regression
> tests will now start showing random failures. We have an awful lot
> of small tables in the tests ...
Maybe what we could do is set h
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I saw what I think was the identical failure last night on my own
>> machine, but it wasn't repeatable. Evidently the planner is changing to
>> a different plan for those queries, but why has this only started
>>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> What really has to happen is it should run analyze on all tables
>> together in a single transaction and commit all the new stats together.
>> Out-of-sync stats can be worse than out-of-date stats.
> One problem with that is that
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> >> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
> >> any ideas ?
> >
> > I saw what I think was the identical failure last night on my
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
>> any ideas ?
>
> I saw what I think was the identical failure last night on my own
> machine, but it wasn't repeat
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
> any ideas ?
I saw what I think was the identical failure last night on my own
machine, but it wasn't repeatable. Evidently the planner is changing to
a dif
"Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
That's just a faulty test:
SELECT t.d1 + i.f1 AS "102" FROM TIMESTAMP_TBL t, INTERVAL_TBL i
WHERE t.d1 BETWEEN '1990-01-01' AND '2001-01-01'
AND i.f
Zdenek Kotala wrote:
Stefan Kaltenbrunner wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
any ideas ?
This test is very sensitive to floating point operations behavior. Any
gcc, libc update on this machine?
nope - in fact nobody was even
Stefan Kaltenbrunner wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
any ideas ?
This test is very sensitive to floating point operations behavior. Any
gcc, libc update on this machine?
Zdenek
---(e
Stefan Kaltenbrunner wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
clownfish just hit the same problem:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=clownfish&dt=2007-07-24%2013:08:29
Stefan
---(end of broadcast)
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
any ideas ?
Stefan
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
20 matches
Mail list logo
