Re: Performance problem. Could it be related to 8.3-beta4?

2008/1/8, Clodoaldo <clodoaldo.pinto.neto@gmail.com>:
> 2008/1/8, Alvaro Herrera <alvherre@commandprompt.com>:
> > Clodoaldo escribió:
> >
> > 8.2:
> >
> > >  Trigger for constraint datas: time=14231.240 calls=880691
> > >  Total runtime: 356862.302 ms
> > > (12 rows)
> > >
> > > Time: 357750.531 ms
> >
> > 8.3:
> >
> > >  Trigger for constraint datas: time=33179.197 calls=877895
> > >  Total runtime: 9546878.520 ms
> > > (13 rows)
> >
> > So what's this constraint and why is it taking longer on the 8.3 server?
>
> fahstats=> \d+ usuarios
>            Table "public.usuarios"
>  Column  |  Type   | Modifiers | Description
> ---------+---------+-----------+-------------
>  usuario | integer | not null  |
>  data    | integer | not null  |
>  wus     | integer | not null  |
>  pontos  | real    | not null  |
> Indexes:
>     "ndx_usuarios_data" btree (data) CLUSTER
>     "ndx_usuarios_usuario" btree (usuario)
> Foreign-key constraints:
>     "datas" FOREIGN KEY (data) REFERENCES datas(data_serial) ON UPDATE
> RESTRICT ON DELETE RESTRICT
> Has OIDs: no
>
> fahstats=> \d+ datas
>                                                 Table "public.datas"
>    Column    |           Type           |
> Modifiers                          | Description
> -------------+--------------------------+-------------------------------------------------------------+-------------
>  data_serial | integer                  | not null default
> nextval('datas_data_serial_seq'::regclass) |
>  data        | timestamp with time zone | not null
>                                |
>  have_data   | boolean                  | not null default true
>                                |
> Indexes:
>     "pk_data" PRIMARY KEY, btree (data)
>     "data_ndx" UNIQUE, btree (data_serial) CLUSTER
> Has OIDs: no

Can someone reproduce or understand this? If so is there a chance to
have it fixed in RC2?

I see there is a post by Tom Lane in the hackers list about mergejoins
but I don't understand if it is the same issue.

Regards, Clodoaldo Pinto Neto