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 performance
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 =
Bruce Momjian writes:
> Thomas F. O'Connell wrote:
>> It seems like this warrants an item somewhere in the release notes,
>> and I'm not currently seeing it (or a related item) anywhere. Perhaps
>> E.1.3.1 (Performance Improvements)? For some of the more extreme
>> UPDATE scenarios I've see
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:
> 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
> a
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 q
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.
