"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
"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
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
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
> 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
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 is ORDER-e
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:
> 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
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
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
11 matches
Mail list logo
