Make use of temp tables

[marco44]

Closes #23

If this goes according to plan, then we can just slightly patch powa archivist to DELETE FROM ONLY to not waste time with those temp tables. They'll just get purged at disconnection

The only issue I see that this could bring is that we'll have lots of distinct queryids on the collector itself, if we decide to manage via powa

We could make disconnection from the database optional so that we can keep the temp tables active, but I really think this temp table mechanism isn't a big price to pay for the dramatic IO reduction it should bring

Anyway, comments are welcome

[marco44]

I really have a big doubt about this, because I suppose I'm probably interfering with the transactions of the app. If that's the case, maybe we need 2 loops, one that initially creates all the temp tables, and then another that populates them

[rjuju]

FWIW this shouldn't cause correctness problem, as the need for a single transaction only exists on the remote servers (the get a consistent timestamp), not on the repository server. It may lead to faster xid consumption and thus amplify any problem related to autovacuum / freezing, but the data itself will be consistent.

[marco44]

Ok, it doesn't work: we need the same ts for all of a snapshot, as it's the way we identify it (for joining between different pieces of data…) => back to the drawing board

[rjuju]

That's very strange, the ts is returned by the source function on the remote server (as we want the remote server's timestamp at the sampling time, not the repository server at the insertion time), so since you're doing a commit on the repository side it shouldn't have any impact on the snapshot's ts.

[marco44]

Yeah, false alarm. I was chasing a strange display problem and thought it was coming from this. It isn't

[frost242]

I'm testing this patch right now. Just a few notes.
Previously, I used pgbouncer to smooth out the collections. With this patch, I was had to disable pgbouncer because it tended to a very huge catalog bloat. Without pgbouncer, the pg_class and pg_attributes tables size remain reasonnable.
After replacing DELETE FROM by DELETE FROM ONLY in the snapshot functions, everything was smoothed out : I have no more lock waits in the logs.
On a side note, temp_buffers is set to 64MB instead of 8MB.

[rjuju]

I don't understand how using pgbouncer can lead to more catalog bloat, do you have any reasoning here?

Also, do you have powa enable on the repository server?

[rjuju]

FWIW this shouldn't cause correctness problem, as the need for a single transaction only exists on the remote servers (the get a consistent timestamp), not on the repository server. It may lead to faster xid consumption and thus amplify any problem related to autovacuum / freezing, but the data itself will be consistent.

[rjuju]

You should modify get_global_tmp_name() to return a tuple with the schema name and the table name separately so there is no need to try to recover the table name afterwards.

[rjuju]

In general I think that the temp table approach could be quite nice, but we will need a lot more work to make it usable for everyone.

To summarise, the current powa-collector behavior when it does a snapshot is;

• get the needed data for each datasource on the remote server using a persistent connection
• connect to the repository server and insert the data
• call the snapshot function for the remote server
• disconnect from the repository server

So the big problem here is that you will need new temporary tables for each datasource and each repository server for each snapshot. This causes 2 problem:

• possibly massive catalog bloat
• infinite number of queryid generated

In other words, as-is the powa-repository server must be reserved for powa and you cannot use pg_stat_statements anymore on that server since you have infinite number of queryid (it will be useless, and probably induce a laughable overhead). Maybe that's already what everyone is doing, but we can't know for sure. And I don't think that we can force this without giving a possibility for the users to opt out of the various problems. So I think that feature will require 2 additional new features :

• the possibility to not use temp tables. If you have just a few remote server it shouldn't matter
• the possibility to use persistent connections on the repository server. It wasn't done like that initially because it allowed you to use a lot more remote servers than what your max_connections is.

And a lot of documentation to explain why and how to configure it. We also have to think about what the default configuration should be. I think that using temp tables but with persistent connections could be sensible.