Re: vacuum and row type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: vacuum and row type
Date: 2011-06-01 22:42:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> I found problem while vacuuming with composite type (version 9.0.4). It's not so
> easy to reproduce, but it's clear what happens.

> CREATE TYPE mytype AS (p point, r float8);
> CREATE TABLE mytable (mt mytype);
> -- create opclass fir GiST
> CREATE INDEX myidx ON mytable USING gist (mt);

> And vacuum fails with message:
> ERROR: could not identify a comparison function for type point

It's worse than that, actually: you'll get the same failure from ANALYZE
even without the GIST index, as long as there's some data in the column.
And even if you try to make ANALYZE back off to use
compute_minimal_stats, it still fails, because there's no btree equality
for type point either.

We've also seen similar failures in respect to things like the planner
trying to use sorting with unsortable composite types. So this issue
isn't really specific to ANALYZE. I'm inclined to think that the most
reasonable fix is to make get_sort_group_operators() and related
functions recursively verify whether the component types can be compared
before they claim that record_eq, array_eq, etc can be used. So that
would require special cases for composites and arrays in those
functions, but at least we'd not need to hack up all their callers.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-06-01 22:47:26 Re: creating CHECK constraints as NOT VALID
Previous Message Robert Haas 2011-06-01 22:25:43 Re: pgpool versus sequences