[HACKERS] Queuing all tables for analyze after recovery

Hi. Some (maybe all) row statistics are lost after the database has recovered after a failover. So it's recommended to ANALYZE all databases in a cluster after recovery. Amazon's AWS RDS (their managed SQL databases service) even sends an email "consider running analyze if your database is

Re: [HACKERS] Queuing all tables for analyze after recovery

On 10/19/2017 10:54 PM, Tom Lane wrote: Uh ... recommended by whom? pg_statistic has exactly the same reliability guarantees as the rest of the system catalogs. Actually I'm not exactly sure what is lost and what is preserved. I'm pretty sure that pg_stat_all_tables and similar views turn

[HACKERS] Queuing all tables for analyze after recovery

Hi. Some (maybe all) row statistics are lost after the database has recovered after a failover. So it's recommended to ANALYZE all databases in a cluster after recovery. Amazon's AWS RDS (their managed SQL databases service) even sends an email "consider running analyze if your database is

Re: [HACKERS] Multicolumn hash indexes

On 09/27/2017 05:57 PM, Tom Lane wrote: If we follow GIST's lead that the leading column is "most important", the idea could be to require a search constraint on the first column, which produces the hash that determines the bucket assignment. Hashes for additional columns would just be payload

[HACKERS] Multicolumn hash indexes

Hi. I've noticed that hash indexes can't currently (in PG10) be multicolumn. Are they technically hard to implement or just nobody took such a feature? I think multicolumn hash indexes should help pretty significantly with queries like: - where username=? and user_post_id=? - where

[HACKERS] pg_restore foreign keys NOT VALID, or [assume] VALID; VALIDATE CONSTRAINT CONCURRENTLY

Hi. A lot of time during pg_restore of a large database is spent on validating all the foreign keys. In contrast to importing data and creating indexes this operation does not parallelize well. So large percentage of parallel restore time ends up using single worker to validate foreign keys

Re: [HACKERS] [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all

W dniu 2016-06-08 o 05:04, Tom Lane pisze: Jim Nasby writes: Is there any significant advantage to not analyzing all columns? Only case I can think of is if you have a fair number of columns that have been toasted; otherwise I'd think IO would completely swamp any

Re: [HACKERS] Implementing Sorting Refinements

On Tue, 08 Jan 2008, [EMAIL PROTECTED] wrote: Well, sorry for hijacking... ummm how did I do that? You replied to a post instead of creating a new, unrelated e-mail. It is different. Just try to use threaded mode of your e-mail client and you'll get the idea. Regards Tometzky -- ...although

Re: [HACKERS] Spoofing as the postmaster

On Sun, 23 Dec 2007, Tom Lane wrote: ISTM we have these action items: 1. Improve the code so that SSL authentication can be used across a Unix-socket connection (we can disable encryption though). I've just realised that there's a problem with SSL with disabled encryption on a unix socket /

Re: [HACKERS] Spoofing as the postmaster

On Sun, 23 Dec 2007, Magnus Hagander wrote: I'm just surprised that people are actually surprised by this. To me, it's just a natural fact that happens to pretty much all systems. And a good reason not to let arbitrary users run processes that can bind to something on your server. Not

Re: [HACKERS] Spoofing as the postmaster

On Sun, 23 Dec 2007, Tom Lane wrote: IIRC, you started out your argument by also saying that we had to move the TCP socket to the reserved range, so as to prevent the equivalent problem in the TCP case. 1. Postmaster must be started as root, thereby introducing security risks of its own