I've done it...
First of all I totally agree with PFC's rant regarding absolute
positioning while browsing datasets. Among other things, it has serious
problems if you have multiple updating your table. Also it's kind of
silly to be doing this in a set based data paradigm.
Recently I've be
Christopher
> > - Present a nifty date selector to choose the records from any
day,
> > hour, minute, second
> > - show them, with "next day" and "previous day" buttons
> >
> > - It's more useful to the user (most likely he wants to know
what
> > happened on 01/05/2005 rather than vie
Who needs a paginated view with 100.000 pages ?
- Select min(date) and max(date) from your table
- Present a nifty date selector to choose the records from any day,
hour, minute, second
- show them, with "next day" and "previous day" buttons
- It's more useful to the user
We have a GUI that let user browser through the record page by page at
about 25 records a time. (Don't ask me why but we have to have this
GUI). This translates to something like
select count(*) from table <-- to give feedback about the DB size
select * from table order by date limit 25 o
I am running Postgre 7.4 on FreeBSD. The main table have 2 million record
(we would like to do at least 10 mil or more). It is mainly a FIFO
structure
with maybe 200,000 new records coming in each day that displace the older
records.
I'm so sorry, but I have to rant XDDD
People wh
aurora <[EMAIL PROTECTED]> writes:
> It would still be helpful if select count(*) can perform well.
If you can settle for an approximate count, pg_class.reltuples might
help you.
regards, tom lane
---(end of broadcast)---
TI
You could also create your own index so to speak as a table that
simply contains a list of primary keys and an order value field that
you can use as your offset. This can be kept in sync with the master
table using triggers pretty easily. 2 million is not very much if you
only have a integer pkey
>>
select * from table order by date limit 25 offset 0
> Do you have an index on the date column? Can you post an EXPLAIN
> ANALYZE for the slow query?
Wow! Now that I look again there are actually 2 date fields. One is
indexed and one is not. Order by was done on the column without index.
Usi
> We have a GUI that let user browser through the record page by page at
> about 25 records a time. (Don't ask me why but we have to have this
> GUI). This translates to something like
>
> select count(*) from table <-- to give feedback about the DB size
Do you have a integer field that is a
On Wed, 2005-10-26 at 15:41, aurora wrote:
> I am running Postgre 7.4 on FreeBSD. The main table have 2 million
> record (we would like to do at least 10 mil or more). It is mainly a
> FIFO structure with maybe 200,000 new records coming in each day that
> displace the older records.
>
> We have a
Do you have an index on the date column? Can you post an EXPLAIN
ANALYZE for the slow query?
-- Mark Lewis
On Wed, 2005-10-26 at 13:41 -0700, aurora wrote:
> I am running Postgre 7.4 on FreeBSD. The main table have 2 million
> record (we would like to do at least 10 mil or more). It is mainly a
I am running Postgre 7.4 on FreeBSD. The main table have 2 million
record (we would like to do at least 10 mil or more). It is mainly a
FIFO structure with maybe 200,000 new records coming in each day that
displace the older records.
We have a GUI that let user browser through the record page by p
12 matches
Mail list logo