Re: [HACKERS] pageinspect: Hash index support

2017-01-28 Thread Ashutosh Sharma
Hi, > Please include tests in your patch. I have posted a sample test suite > in > , > which you could use. > > Also, as mentioned before, hash_metapage_info result fields spares and > mapp should be

Re: [HACKERS] pageinspect: Hash index support

2017-01-28 Thread Ashutosh Sharma
> The heap tuple is on page 3407872 at line pointer offset 12584? > That's an awfully but not implausibly big page number (about 26GB into > the relation) and an awfully and implausibly large line pointer offset > (how do we fit 12584 index tuples into an 8192-byte page?). Also, the > fact that

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-28 Thread Cat
On Fri, Jan 27, 2017 at 11:03:05AM -0500, Stephen Frost wrote: > Well, I did get the impression that you weren't thinking about that, > which is actually kind of surpirsing to me. Lots of things work on "the > current query buffer", which is the last query (successful or not, to be > clear..): >

Re: [HACKERS] pg_hba_file_settings view patch

2017-01-28 Thread Tom Lane
I wrote: > I spent awhile hacking on this, and made a lot of things better, but > I'm still very unhappy about the state of the comments. I made another pass over this, working on the comments and the docs, and changing the view name to "pg_hba_file_rules". I think this version is committable if

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

2017-01-28 Thread Tom Lane
Peter Eisentraut writes: > What I liked about it is that it makes it a bit easier to compare the > estimate and actual for each node. Hmm, you'd have to make some effort to line up those fields, if you wanted that to be a thing. regards,

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

2017-01-28 Thread Peter Eisentraut
On 1/28/17 3:24 PM, Gavin Flower wrote: > How about have a GUC to control the formatting of how it is displayed? > > Could also include maximum line width (default 'infinite'), and word > wrapping rules, ... You can already configure that in psql. You can also use the yaml format if you want

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

2017-01-28 Thread Gavin Flower
On 29/01/17 05:31, Pavel Stehule wrote: 2017-01-28 17:09 GMT+01:00 Tom Lane >: Pavel Stehule > writes: > Now EXPLAIN ANALYZE produce too wide rows for usage in presentations

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

2017-01-28 Thread Fabrízio de Royes Mello
On Sat, Jan 28, 2017 at 4:26 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > > On Fri, Jan 27, 2017 at 8:53 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > > > On 1/26/17 1:20 PM, Fabrízio de Royes Mello wrote: > > > Ok, but doing in that way the syntax

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

2017-01-28 Thread Fabrízio de Royes Mello
On Fri, Jan 27, 2017 at 8:53 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > On 1/26/17 1:20 PM, Fabrízio de Royes Mello wrote: > > Ok, but doing in that way the syntax would be: > > > > COMMENT ON DATABASE CURRENT_DATABASE IS 'comment'; > > Yes, that's right. We also have

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-01-28 Thread Corey Huinker
> > > I'm wondering what pg would do on "EXISTS(SELECT 1 FROM customer)" if > there are many employees. EXPLAIN suggests a seq_scan, which seems bad. > With "(SELECT COUNT(*) FROM pgbench_accounts) <> 0" pg seems to generate an > index only scan on a large table, so maybe it is a better way to do

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-28 Thread Daniel Verite
Christoph Berg wrote: > A workaround is to submit queries using "\x\g\x", but that's ugly, > clutters the output with toggle messages, and will forget that "\x > auto" was set. > > Mysql's CLI client is using \G for this purpose, and adding the very > same functionality to psql fits

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

2017-01-28 Thread Pavel Stehule
2017-01-28 17:58 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > 2017-01-28 17:09 GMT+01:00 Tom Lane : > >> Seems like that would make a difference in only a tiny minority of > >> situations. In a deeply nested plan you'll have

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

2017-01-28 Thread Tom Lane
Pavel Stehule writes: > 2017-01-28 17:09 GMT+01:00 Tom Lane : >> Seems like that would make a difference in only a tiny minority of >> situations. In a deeply nested plan you'll have trouble no matter >> what, and it's not uncommon that the node name

Re: [HACKERS] pageinspect: Hash index support

2017-01-28 Thread Ashutosh Sharma
Hi, Please find my reply inline. > In hash_bimap_info(), we go to the trouble of creating a raw page but > never do anything with it. I guess the idea here is just to error out > if the supplied page number is not an overflow page, but there are no > comments explaining that. Anyway, I'm not

Re: [HACKERS] pg_hba_file_settings view patch

2017-01-28 Thread Tom Lane
I wrote: > I'm still not very happy about the choice of view name ... After looking over this thread again, I think that we should go with pg_file_hba_rules or perhaps pg_hba_file_rules. I see that options like that were discussed and rejected earlier, but I feel the arguments against were based

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

2017-01-28 Thread Pavel Stehule
2017-01-28 17:09 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > Now EXPLAIN ANALYZE produce too wide rows for usage in presentations > > > What do you think about possibility to implement >>optional<< alternative > > formatting. > > Now: > > node

Re: [HACKERS] Removing link-time cross-module refs in contrib

2017-01-28 Thread Tom Lane
Noah Misch writes: > ... adding $(pkglibdir) to rpath is obsolete, now that this ceased to link to > hstore explicitly. OK... > For consistency with longstanding src/pl/plpython practice, $(python_libspec) > should always have an accompanying $(python_additional_libs). This

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

2017-01-28 Thread Tom Lane
Pavel Stehule writes: > Now EXPLAIN ANALYZE produce too wide rows for usage in presentations > What do you think about possibility to implement >>optional<< alternative > formatting. > Now: > node name (estimation) (actual) > Alternative: > node name (estimation) >

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

2017-01-28 Thread Pavel Stehule
2017-01-28 16:22 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 1/28/17 2:36 AM, Pavel Stehule wrote: > > Now EXPLAIN ANALYZE produce too wide rows for usage in presentations > > > > What do you think about possibility to implement >>optional<< > > alternative formatting. >

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

2017-01-28 Thread Peter Eisentraut
On 1/28/17 2:36 AM, Pavel Stehule wrote: > Now EXPLAIN ANALYZE produce too wide rows for usage in presentations > > What do you think about possibility to implement >>optional<< > alternative formatting. > > Now: > > node name (estimation) (actual) > > Alternative: > > node name

Re: [HACKERS] Transactions involving multiple postgres foreign servers

2017-01-28 Thread Peter Eisentraut
On 1/26/17 4:49 AM, Masahiko Sawada wrote: > Sorry, I attached wrong version patch of pg_fdw_xact_resovler. Please > use attached patch. So in some other thread we are talking about renaming "xlog", because nobody knows what the "x" means. In the spirit of that, let's find better names for new

[HACKERS] Z-curve spatial index

2017-01-28 Thread Boris Muratshin
Hi hackers, I've implemented subj algorithm as PostgreSQL extension. It looks like this realization is such as fast as R-Tree but sufficiently more simple & compact. Here (https://habrahabr.ru/post/319810/) or here (

Re: [HACKERS] Microvacuum support for Hash Index

2017-01-28 Thread Amit Kapila
On Fri, Jan 27, 2017 at 5:15 PM, Ashutosh Sharma wrote: >> >> Don't you think we should try to identify the reason of the deadlock >> error reported by you up thread [1]? I know that you and Ashutosh are >> not able to reproduce it, but still I feel some investigation is