Quoting Tom Lane <[EMAIL PROTECTED]>:
[EMAIL PROTECTED] writes:
In the 8.0 release notes, (section E.10.4.1), I noticed this
statement:
Improve B-tree index performance for duplicate keys (Dmitry Tkach, Tom)
This improves the way indexes are scanned when many duplicate
values
I'm currently running postgresql 7.4.8. Our two biggest tables have
indexes on (x, y), where x, y are integers, and there are often
many y values per x value. The ratio can be anywhere from 1:1 to 20:1.
In the 8.0 release notes, (section E.10.4.1), I noticed this
statement:
Improve B-tree
[Sorry if this is a repeat. Thought I sent this but I didn't see
it come through the mailing list.]
Quoting Tom Lane <[EMAIL PROTECTED]>:
[EMAIL PROTECTED] writes:
I have this table and index:
create table t(id int, hash int);
create index idx_t on t(hash);
The value of the hash col
Quoting Tom Lane <[EMAIL PROTECTED]>:
[EMAIL PROTECTED] writes:
I have this table and index:
create table t(id int, hash int);
create index idx_t on t(hash);
The value of the hash column, which is indexed, is a pseudo-random
number. I load the table and measure the time per insert.
I have this table and index:
create table t(id int, hash int);
create index idx_t on t(hash);
The value of the hash column, which is indexed, is a pseudo-random
number. I load the table and measure the time per insert.
What I've observed is that inserts slow down as the table grows to
1,0
I have a postgresql 7.4.8 database which has the same table
declarations in several schemas. My application accesses each schema
from a single thread; there is never more than one thread accessing a
schema at a time.
To try increasing concurrency, I've tried using multiple threads per
schema. The
I'm using postgres 7.4.6 and I've created a table as follows:
create table t(dh int, fh int, fn int, x bytea, ...)
create index idx_dh_fh on t(dh, fh);
I have this query:
select *
from t
where dh = 1
and fn > 1000
and x = 'abc'
order by fn;
The optimizer use
My company's product is developing a product using postgres 7.4.6 on a
Linux 2.6.10 or 11 kernel, (don't have the exact version handy). We
do "vacuum verbose analyze" daily. Two days after the database was
created and loaded with a small amount of data (megabytes), the
postgres logs had this line:
I'm using postgresql 7.4.6 on RH9. My application includes a
long-running Java process responsible for database access. I'd like to
have this Java process initiate a daily VACUUM and, one way or
another, log VACUUM output.
- Is there some way to get VACUUM output via JDBC?
- If not, how can I ge
Quoting Bruno Wolff III <[EMAIL PROTECTED]>:
> On Thu, Nov 11, 2004 at 14:17:41 -0500,
> [EMAIL PROTECTED] wrote:
> > ...
> > Suppose 8.0 is released in December or January. Is it a sane thing
> > to put 8.0 in a shipping product within the first two months of its
> > release? I know that 8.0 is
My company has a product in beta which uses Postgres 7.4.3. We expect
to have a code freeze for our 1.0 product in March 2005. I'd really
like to use Postgres 8.x in our 1.0 product. We're especially looking
forward to the background writer and tablespaces.
Is the 8.0 release date known?
Suppose
[Sorry if this is a repeat. I think the first message may have
been rejected due to an attachment.]
I'm using PostgreSQL 7.3.4 on RH9. Data and logs are on separate
disks. (These are low-end IDE disks. That part of the problem
is out of my control.)
When a checkpoint occurs, all operations slow w
Quoting [EMAIL PROTECTED]:
> When a checkpoint occurs, all operations slow way, way down.
> The attached spreadsheet (xls file, prepared in OO so unlikely
> to be dangerous) shows a run of a few hours, and the various spikes
> every 25-30 minutes seem consistent with checkpointing. The
> applicat
13 matches
Mail list logo
