> I wouldn't call myself a novice, but yes - this surprised me a little.
> Now it seems so natural ... I think there should be a clear explanation
> / example in the docs about this - I've read the documentation on RULE
> sytem several times and as far as I remember.
... and as far as I remember t
>> But I don't understand why the nextval('sessions_id_seq') is evaluated
>> multiple times? Even when I do
>
> RULE expand like macros, so every expression passed in is simply copied
> to each place, leading to multiple evaluations.
>
> If you've played with the C preprocessor: that has the same
On Wed, Feb 07, 2007 at 08:09:57PM +0100, Tomas Vondra wrote:
> But I don't understand why the nextval('sessions_id_seq') is evaluated
> multiple times? Even when I do
RULE expand like macros, so every expression passed in is simply copied
to each place, leading to multiple evaluations.
If you've
> It's likely to be a problem because of multiple evaluations of volatile
> expressions
> in the rule rewrite systemshort example:
>
> CREATE TABLE sessions(id SERIAL PRIMARY KEY, value TEXT);^
> CREATE TABLE sessions_100(CHECK(id BETWEEN 1 AND 100), PRIMARY KEY(id))
> INHERITS(sessions);
On Tue, 06 Feb 2007 21:28:49 +0100, Tomas Vondra <[EMAIL PROTECTED]> wrote:
>
> We're using sequence to generate the sessions(id) value, but that should
> not be a problem - with the structure / rules everything works fine (the
> current value in sessions_id_seq is about 870 so the values ar
> If there´s only the insert_850 RULE then everything works as expected -
> the
> insert prints "INSERT 0 0", the row is inserted into the correct partition
> which is sessions_850 - I can fetch it using either
>
> SELECT * FROM sessions WHERE id = currval('sessions_id_seq');
>
> or dire
> Suddenly stops working, or continues doing exactly what it did before?
> I'm wondering if you are relying on a cached plan that doesn't include
> the new rule.
>
> regards, tom lane
>
If there´s only the insert_850 RULE then everything works as expected - the
insert pr
Tomas Vondra <[EMAIL PROTECTED]> writes:
> As I already said - it works until I create a rule for the next
> partition (not used yet) - then is suddenly stops working.
Suddenly stops working, or continues doing exactly what it did before?
I'm wondering if you are relying on a cached plan that does
> Looks to me as though you have forgottent the table inheritance part of the
> table partitioning trick. Are you sure that sessions_90 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(*) FR
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> db=> INSERT INTO sessions(... non-pk columns ...) VALUES (... data ...);
> INSERT 0 0
> db=> SELECT * FROM sessions WHERE id = currval('sessions_id_seq');
> (0 rows)
>
> which seems really strange to me. We're using sequence to generate the
>
Hi,
we're running PostgreSQL 8.1.4 and I've encountered some strange
problems with partitioning / rules, and I really don't know how to
fix it.
We have a table 'sessions' partitioned along the 'id' column which is a
primary key. Each partition holds at most 500.000 rows, i.e. partition
'sessions_
11 matches
Mail list logo
