Hi,
I'm fighting with problem with indexes. I read documentation about
performance tips, about internal logic functions which are making decision
if to use or not use indexes, etc. and I'm still failed. I'm not SQL
guru and I don't know what to do now. My tables and indexes looks like
...
CREAT
> netacc=> EXPLAIN (SELECT SUM(counterfrom) AS from,
> SUM(counterto) AS to,
> floor((985098900 - date_part('epoch', counterstamp)) / 300)
> AS sequence
> FROM counters WHERE line='absolonll' AND date_part('epoch',
> ) counterstamp > 984978900 GROUP BY sequence, line) ...
I would guess the pr
> I would guess the problem is the restriction on counterstamp, because
> written like that, it probably can't use the index.
>
> try something where you avoid the use of the date_part function e.g.:
> AND counterstamp > '2001-07-26 00:00:00.0'
I will try it, but it use the index when t
> The index is only used for the line= part of the where clause
> with your query. With many rows the "line=" is not selective enough
> to justify the index.
Hi,
I tried you suggestion about 'AND counterstamp > '2001-07-26 00:00:00.0' and
it works and index is used :) But, whole query run for
> The index is only used for the line= part of the where clause
> with your query. With many rows the "line=" is not selective enough
> to justify the index.
I tried move only needed data into new table and change query into ...
netacc=> EXPLAIN SELECT counterfrom AS from, counterto AS to,
fl
Hi
PostgreSQL7.1 is now running on AIX5L( S85, 6GB memory, 6CPU), which was
running on Linux before(Pentium3, 2CPU, as far as I
remember...sorry..).
The performance( on AIX5L ) is just half as good as the one( on Linux ).
I compiled PostgreSQL on AIX5L ofcourse.
I haven't configured it wh
On Fri, 27 Jul 2001, Robert Vojta wrote:
> netacc=> EXPLAIN (SELECT SUM(counterfrom) AS from, SUM(counterto) AS to,
> floor((985098900 - date_part('epoch', counterstamp)) / 300) AS sequence
> FROM counters WHERE line='absolonll' AND date_part('epoch', counterstamp)
> > 984978900 GROUP BY sequence
>Impossible to tell, since you haven't said word one about what this
>box is or what it can do. If it were plain storage hardware, why do
thanks for your reply. Yes I know it's hard to explain
why we plan to do what I described without explaining more
about the hardware we have. So it sounds
I got a mailbox full for Peter, so here is information.
Larry ROsenman
- Forwarded message from Larry Rosenman <[EMAIL PROTECTED]> -
From: Larry Rosenman <[EMAIL PROTECTED]>
Subject: Caldera OpenUNIX 8
Date: Fri, 27 Jul 2001 11:58:01 -0500
Message-ID: <[EMAIL PROTECTED]>
User-Agent: Mutt
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (mlw)
wrote:
> I was looking over the todo list and saw that someone wanted to support
> XML. I have some quick and dirty stuff that could be used.
>
I'm not clear from the TODO what that "XML support" might involve. The
reference to pg_dump sugg
In article <9jrn78$pbv$[EMAIL PROTECTED]>, "Colin 't Hart" <[EMAIL PROTECTED]>
wrote:
>> Should we add this to /contrib?
>
> I think so, at least until we get something better.
>
I'm happy for you to add it, if you're willing to have it (It is meant to
be under the PostgreSQL license). I agree
I believe Caldera has submitted changes to the autoconf people to
update config/config.guess to support OpenUNIX 8.
Our current stuff BREAKS unless you use the SCOMPAT magic to look like
a UnixWare 7.1.1 box.
Who needs to pick up an update?
Larry
--
Larry Rosenman http
Skip the patch for configure.in in that last one, use this in it's
place (I missed one sysv5uw).
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
In
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (mlw)
> wrote:
> > I was looking over the todo list and saw that someone wanted to support
> > XML. I have some quick and dirty stuff that could be used.
> >
>
> I'm not clear from the TODO what that "XML support" mig
markw wrote:
: [...] Actually I have been thinking about a couple projects I have
: done. Vendors like to think XML is a way to distribute databases.
I would find it very helpful to see a table of what sorts of XML
functionality each major vendor supports.
: So a parser that can scan a DTD a
At 01:36 27.07.2001 -0400, you wrote:
>"Steve Howe" <[EMAIL PROTECTED]> writes:
> > Is anybody trying to solve the 8191 bytes query limit from libpq
> > windows port ???
>
>I think it's *your* responsibility, at least to identify what's going
>on. This is an open source project, and that
Tom Lane wrote:
>
> "Steve Howe" <[EMAIL PROTECTED]> writes:
> > Is anybody trying to solve the 8191 bytes query limit from libpq
> > windows port ???
>
> FWIW, if the problem is real (which I still misdoubt),
Yes it's real.
Error handling seems the cause. When "Error: pqReadData() --
r
Michael Rudolph wrote:
>
> To let all of you know the status of my problem: I got on one large
> step when realized, that I forgot a "vacuum analyze" after copying the
> data. When I did this, my performance gain was huge - but didn't reach
> the performance of centura at all. It is still a bit sl
I was looking over the todo list and saw that someone wanted to support XML. I
have some quick and dirty stuff that could be used.
OK, what should the feature look like?
Should it be grafted onto pg_dump or should a new utility pg_xml be created?
How strict should it be? A stricter parser is ea
> Should we add this to /contrib?
I think so, at least until we get something better.
Cheers,
Colin
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so t
20 matches
Mail list logo
