Tom Lane [EMAIL PROTECTED] writes:
It's usually better to use partitioning rules that have something to
do with the WHERE-clauses you'd be using anyway. For instance, try
to partition on ranges.
I agree and tried to create new partitioned tables. But now I ran into
some other
I try to partition a large table (~ 120 mio. rows) into 50 smaller
tables but using the IMO immutable %-function constraint exclusion
does not work as expected:
CREATE TABLE tt_m (id1 int, cont varchar);
CREATE TABLE tt_0 (check (id1 % 50 = 0)) INHERITS (tt_m);
CREATE TABLE tt_1 (check (id1 % 50
Which effects have UPDATEs on REFERENCEd TABLEs when only columns in the
referenced table are updated which are not part of the FOREIGN KEY
constraint?
I have one master-table like
create table t_master (
m_id serial primary key,
m_fld1 ...,
m_fld2 ...,
...
)
The table above is
Tom Lane [EMAIL PROTECTED] writes:
Denis [EMAIL PROTECTED] writes:
There were 1905028 unused item pointers.
The unused item pointers number seems a bit high, but otherwise that
looks pretty reasonable.
Is it possible that the particular row you were updating has been
updated quite a lot of
Tom Lane [EMAIL PROTECTED] writes:
Martin Lesser [EMAIL PROTECTED] writes:
What causes this unused item pointers and which impact do they have
regarding performance?
The direct performance impact is really pretty minimal (and none at
all on indexscans, AFAIR). The reason Denis' number drew
Hi,
the time needed for a daily VACUUM on a table with about 28 mio records
increases from day to day. What's the best way to avoid this? A full
vacuum will probably take too much time, are there other ways to keep
vacuum performant?
The database was updated to postgres-8.0 on Jun 04 this year.
