It seems like pgsql-general would be the right list for this so I am
going to post it there rather, sorry for the noise...
It appears (and I am open to correction) that autovacuum is not
operating correctly in 8.3.0. I have a vanilla installation where
autovacuum is enabled, and is running with
It appears (and I am open to correction) that autovacuum is not
operating correctly in 8.3.0. I have a vanilla installation where
autovacuum is enabled, and is running with all the default settings.
I have a table which is continually having rows added to it (~50/sec).
For the sake of this exa
It seems to me that postgresql doesn't use indexes when being asked
for an ordered result sets from a partitioned table. I have an
application where this is critical, but I was hoping to use partitions
because of the ease of rotating out old rows.
metadb=> explain select * from l order by a
It seems to me that postgresql doesn't use indexes when being asked for
an ordered result sets from a partitioned table. I have an application
where this is critical, but I was hoping to use partitions because of
the ease of rotating out old rows.
Simply put, I have a table called LineItems wh
I have a very simple table set:
Transactions:
transaction_key PRIMARY KEY
client TEXT
time TIMESTAMP
LineItems
transaction_key INT
amount INT
A query to print the contents of transactions with a sum of the line
item amounts provides a very suboptimal result. The problem seems to be
the GROUP
If I reduce the precision to 3 for the timestamps it appears to work
although it makes me nervous.
With float timestamps, you're fooling yourself if you think those
numbers past the decimal are reliable.
Should I just recompile to use integer datetimes? I would like to
have at least micros
I have a problem in comparing a TIMESTAMP field with a timestamp
literal. I presume it is to do with the floating point representation of
the timestamp but I was wondering if there is an easy work around
without having to recompile postgres to use integer datetimes.
Basically if I issue a "SEL
> > But if I want the next item following t=(a=10,b=100,c=1000):
>
> > select * from T
> > where (a=10 AND b=100 AND c>1000) OR (a=10 AND b>100) OR (a>10)
> > order by a,b,c;
>
> The correct way to handle this is to use a SQL-spec row comparison:
>
> where (a,b,c) > (10,100,1000)
>
> Unfortunate
Hi,
I am not sure this can be done but I'm trying to constrain a sorted set
efficiently using a multicolumn index in postgres. The (simplified)
scenario is this:
CREATE TABLE T
(
a INT,
b INT,
c INT
);
CREATE INDEX t_idx ON T(a,b,c);
Now I can sort using t_idx:
select * from T order by
