From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
---|---|
To: | Greg Sabino Mullane <greg(at)turnstep(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: partitioning / rules - strange behavior |
Date: | 2007-02-05 07:01:31 |
Message-ID: | 45C6D64B.6060506@fuzzy.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Looks to me as though you have forgottent the table inheritance part of the
> table partitioning trick. Are you sure that sessions_900000 inherit from
> the sessions table? Does a direct count from the table referenced by the
> rule return a non-zero count? In other words:
>
> SELECT count(*) FROM sessions_900000 where id = currval('sessions_id_seq');
No, the tables are inherited, i.e. there's something like
CREATE TABLE sessions_8000000 (
CHECK (id BETWEEN 8000000 AND 8499999
) INHERITS (sessions);
I've checked this for all the partitions (we're using three right now)
as well as the direct count (returns nothing).
As I already said - it works until I create a rule for the next
partition (not used yet) - then is suddenly stops working.
> (or some other similar table) may show your "missing" rows. The other
> possibility is that the you are not using sessions_id_seq in the way
> you think you are.
What do you mean? I do a 'SELECT currval(...)' after the insert and it
gives me the right value. It works until I create the next RULE, so this
does not seem as a sequence problem.
Tomas
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-02-05 07:16:49 | Re: partitioning / rules - strange behavior |
Previous Message | Greg Sabino Mullane | 2007-02-05 01:00:38 | Re: partitioning / rules - strange behavior |