Hi
We do it with Skytools. In addition to replication with Londiste it hs lot's
of other useful scripts for keeping online database small and healthy.
Asko
On 10/31/07, Joanne Salerno <[EMAIL PROTECTED]> wrote:
>
> I have two Postgres databases (7.4 and 8.24) within the same network on
> LINUX
hi,
I recently did a dist-upgrade from sarge to etch on a server with a
bunch of postgresql databases (7.4.9). Many of these had encoding set
as unicode and contained a lot of unicode data. After the dist-
upgrade, I find some of these databases are now encoded as latin1 -
and I cannot pro
Andreas Joseph Krogh <[EMAIL PROTECTED]> writes:
> AFAICS the information about the *total* number of rows is in the "result"
> somehow. When I execute a "limit 1" query with EXPLAIN ANALYZE, I se the
> total number of columns in "rows=200819", so the information is there.
That's only an estimat
On Monday 05 November 2007 15:18:22 Tom Lane wrote:
> Andreas Joseph Krogh <[EMAIL PROTECTED]> writes:
> > AFAICS the information about the *total* number of rows is in the
> > "result" somehow. When I execute a "limit 1" query with EXPLAIN ANALYZE,
> > I se the total number of columns in "rows=200
Andreas Joseph Krogh <[EMAIL PROTECTED]> writes:
> On Monday 05 November 2007 15:18:22 Tom Lane wrote:
>> That's only an estimate. Since the query doesn't get executed to
>> completion thanks to the LIMIT, Postgres really has no idea whether
>> the estimate is accurate.
> Ok. The query is ORDER-e
Sorry for not being clear enough. What i meant is how aware the optimizer is
about the transitivity of operators.
I agree that the more join clauses a query gets, the more flexibility the
optimizer gets to pick an optimal plan.
what i expected is that the optimizer will use the redundant p
> Andreas Joseph Krogh <[EMAIL PROTECTED]> writes:
>> On Monday 05 November 2007 15:18:22 Tom Lane wrote:
>>> That's only an estimate. Since the query doesn't get executed to
>>> completion thanks to the LIMIT, Postgres really has no idea whether
>>> the estimate is accurate.
>
>> Ok. The query i
Ehab Galal <[EMAIL PROTECTED]> writes:
> what i expected is that the optimizer will use the redundant predicates
> to create the plan, but the execution plan itself will not execute a
> redundant predicate.
> O! I see, it's my mistake. The example i mentioned was not a good example. I
> tried th
On Monday 05 November 2007 16:27:03 Gregory Stark wrote:
> > Andreas Joseph Krogh <[EMAIL PROTECTED]> writes:
> >> On Monday 05 November 2007 15:18:22 Tom Lane wrote:
> >>> That's only an estimate. Since the query doesn't get executed to
> >>> completion thanks to the LIMIT, Postgres really has no
"Andreas Joseph Krogh" <[EMAIL PROTECTED]> writes:
> That's what I'm doing now. I run the query with "limit+1" as limit and if it
> results in more than limit, I know there is more data and I run count(*) to
> count them all. But count(*) cannot use indices in PG so it's limited in
> speed any
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Andreas Joseph Krogh" <[EMAIL PROTECTED]> writes:
>
>> That's what I'm doing now. I run the query with "limit+1" as limit and if it
>> results in more than limit, I know there is more data and I run count(*) to
>> count them all. But count(*) cannot
11 matches
Mail list logo
