On Sat, 29 Nov 2003, Andreas Heissenberger wrote:
> Hi,
>
> I want to set a session id based on a session timeout per user. I have a very large
> logfile with more than 1.3 Mio records and look for a very efficient solution -
> maybe with PL/pgSQL .
>
> The important columns in the table are:
ow wrote:
My impression was that the index "I_bca" covers the query, hence there should
not be a need to go to the table itself. Why would it?
Postgres always has to go to the table. The ability to read data
directly from indexes (ala other RDBMSs) has been discussed, but not
implemented. IIRC it
Hi,
I want to set a session id based on a session
timeout per user. I have a very large logfile with more than 1.3 Mio records and
look for a very efficient solution - maybe with PL/pgSQL
.
The important columns in the table are: access
timestamp and userid sorted by userid and
access t
--- Joe Conway <[EMAIL PROTECTED]> wrote:
> >
> >>explain select b, c, a
> >>from test
> >>group by b, c, a
> >>having count(*) > 1
>
> Why would you expect this to use an index scan when it needs to read the
> entire table? If you read the whole table (or even a significant
> fraction of it),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I am migrating an SQL Server 2000 database to Postgres 7.3.4 running
> on RH Linux 7.2. While migrating I encounter SQL Server REVERSE( )
> function, seems no such functions at Postgres.
>
> Is there a equivalent function available at Postgres? P
On Sat, 29 Nov 2003, ow wrote:
> Am trying to find duplicate values in a large table (about 80M records).
> Somehow, none of the two (2) queries (see below) is using the index "I_bca"
> that, I believe, should've been used.
As a side note, to help determine if it should be used, you probably wan
jasiek wrote:
On Sat, 29 Nov 2003 08:49:24 -0800 (PST), ow wrote
explain select b, c, a
from test
group by b, c, a
having count(*) > 1
Why would you expect this to use an index scan when it needs to read the
entire table? If you read the whole table (or even a significant
fraction of it), a seq
ow <[EMAIL PROTECTED]> writes:
> Am trying to find duplicate values in a large table (about 80M records).
> Somehow, none of the two (2) queries (see below) is using the index "I_bca"
> that, I believe, should've been used.
Those plans are perfectly reasonable (particularly the GroupAggregate one)
On Sat, 29 Nov 2003 08:49:24 -0800 (PST), ow wrote
> explain select b, c, a
> from test
> group by b, c, a
> having count(*) > 1
I'm not sure about 7.4 aggregate improvements, but <=7.3 didn't work good
with aggregates at all. Maybe it's not directly an answer to your question,
but try theses qu
pgSql 7.4.0
Hi,
Am trying to find duplicate values in a large table (about 80M records).
Somehow, none of the two (2) queries (see below) is using the index "I_bca"
that, I believe, should've been used.
Any ideas? Thanks
--
CREATE
11 matches
Mail list logo