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
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. Then
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 test at
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
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfishdt=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
Stefan Kaltenbrunner wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfishdt=2007-07-24%2005:30:13
clownfish just hit the same problem:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=clownfishdt=2007-07-24%2013:08:29
Stefan
---(end of
Stefan Kaltenbrunner wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfishdt=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
Zdenek Kotala wrote:
Stefan Kaltenbrunner wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfishdt=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 [EMAIL PROTECTED] writes:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfishdt=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.f1
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfishdt=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
Tom Lane [EMAIL PROTECTED] writes:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfishdt=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.
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfishdt=2007-07-24%2005:30:13
any ideas ?
I saw what I think was the identical failure last night on my own
machine, but
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 it will
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
recently?
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
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
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-of-date stats.
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.
Out-of-sync stats
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 in the
20 matches
Mail list logo
