Re: changeset generation v5-01 - Patches & git tree

On 28 June 2013 17:10, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> > But to tell the truth, I'm mostly exercised about the non-unique
> > syscache. I think that's simply a *bad* idea.
>
> +1.
>
> I don't think the extra index on pg_class is going to hurt that much,
> even if we create it always, as long as we use a purpose-built caching
> mechanism for it rather than forcing it through catcache.

Hmm, does seem like that would be better.

> The people
> who are going to suffer are the ones who create and drop a lot of
> temporary tables, but even there I'm not sure how visible the overhead
> will be on real-world workloads, and maybe the solution is to work
> towards not having permanent catalog entries for temporary tables in
> the first place. In any case, hurting people who use temporary tables
> heavily seems better than adding overhead to every
> insert/update/delete operation, which will hit all users who are not
> read-only.
>

Thinks...

If we added a trigger that fired a NOTIFY for any new rows in pg_class that
relate to non-temporary relations that would optimise away any overhead for
temporary tables or when no changeset extraction was in progress.

The changeset extraction could build a private hash table to perform the
lookup and then LISTEN on a specific channel for changes.

That might work better than an index-plus-syscache.

> On the other hand, I can't entirely shake the feeling that adding the
> information into WAL would be more reliable.

I don't really like the idea of requiring the relid on the WAL record. WAL
is big enough already and we want people to turn this on, not avoid it.

This is just an index lookup. We do them all the time without any fear of
reliability issues.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services