Craig Ringer wrote:
> PostgreSQL has to trust the hardware and the OS to do their jobs. If the
> OS is, unbeknownst to PostgreSQL, flipping the high bit in any byte
Might not even be the OS - it could be the stars (through cosmic rays).
http://www.eetimes.com/news/98/1012news/ibm.html
'"This cl
Jeff Davis wrote:
> On Mon, 2006-11-27 at 12:44 -0800, Ron Mayer wrote:
>> Shouldn't the results of this query shown here been sorted by "b" rather
>> than by "a"?
>>
>> I would have thought since "order by b" is in the outer sql sta
I have a long query something like
select slow_function(col) from large_table;
and half way through the query, in a separate connection, I
CREATE OR REPLACE slow_function
I was surprised to see that some of the rows in my select
were processed by the old definition and some by the new.
I w
Using the int_array_enum function from contrib/intagg I can crash the 8.0.2
backend when I pass it an empty array.
fli=# select int_array_enum('{}'::int[]);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the
Bruce Momjian wrote:
This is going to be a backward compatibility problem
You say that as if it's a bad thing.
In a previous thread, I think Bruce and Tom both commented on
ripping out some of the weird undocumented interval behavior:
http://archives.postgresql.org/pgsql-patches/2003-09/msg00134.
On Fri, 2 Aug 2002, Tom Lane wrote:
> >> it would be interesting to see what contrib/pgstattuple shows...
> >> if you can run that conveniently.
> > Gladly, if I'm shown where to find it.
> If you built from a source package, the contrib stuff should be in that
> package. If you used RPMs, look
On Fri, 2 Aug 2002, Tom Lane wrote:
>
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > On a number of my tables, "analyze" seems to be putting the wrong value of
> > "reltuples" in pg_class. "vacuum" seems to be doing the right thing.
>
On a number of my tables, "analyze" seems to be putting the wrong value of
"reltuples" in pg_class. "vacuum" seems to be doing the right thing.
An example of the failure mode is shown below. Please let me know what
additional info I could supply if more info would help.
Ron
logs2=# selec
On a very big table (a data warehouse with >10 million rows), I frequently
run queries looking at the past few days.
However queries like this:
select count(*)
from fact
where dat > (current_date - interval '1 days');
never uses the index I have on "fact". (Thanks to previous querie
On Wed, 3 Apr 2002, Tom Lane wrote:
>
> I'm confused. Your examples show the planner correctly estimating the
> indexscan as much cheaper than the seqscan.
>...
> Cut-and-paste mistake here somewhere, perhaps? The plan refers to fact
> not fact_by_dat.
My apologies... It was indeed doing the
On Tue, 26 Mar 2002, Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
> >> I'm particularly interested in the correlation estimate for the dat
> >> column. (Would you happen to have an idea whether the data has been
> >> inserted more-or-l
ion
I had earlier today...
On Tue, 26 Mar 2002, Tom Lane wrote:
>
> Ron Mayer <[EMAIL PROTECTED]> writes:
> >> I'm particularly interested in the correlation estimate for the dat
> >> column. [...]
> >
> > [...]
>
> The correlation estimate for d
On Tue, 26 Mar 2002, Tom Lane wrote:
>
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > [...] pretty large, PostgreSQL suddenly stopped using indexes [...]
> [...]
>
> 212K estimate for 180K real is not bad at all. So the problem is in the
> cost models not the initia
In porting a pretty large (10s of millions of records) data warehouse
from Oracle to PostgreSQL,
Once some of my tables started getting pretty large, PostgreSQL
suddenly stopped using indexes when I use expressions like "col = value"
decreasing performance by 20X. This meant that my daily
14 matches
Mail list logo
