Re: [HACKERS] pageinspect: Hash index support

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 array

Re: [HACKERS] pageinspect: Hash index support

> 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 th

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

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

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

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, tom lane -- Sent via pgsql-hack

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

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 to

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

On 29/01/17 05:31, Pavel Stehule wrote: 2017-01-28 17:09 GMT+01:00 Tom Lane >: Pavel Stehule mailto:pavel.steh...@gmail.com>> writes: > Now EXPLAIN ANALYZE produce too wide rows for usage in presentations > What do you think about possibility to impleme

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

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 would

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

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 ALTE

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

> > > 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 i

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

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 nicel

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

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 trouble no matter > >> what, and it's not uncommon that the node na

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

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 line isn't the widest >> thing anyway. > It i

Re: [HACKERS] pageinspect: Hash index support

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 su

Re: [HACKERS] pg_hba_file_settings view patch

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 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 name (estimation) (actual) > > Alternative: >

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

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 matters on > few con

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

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) >(actual)

Re: [HACKERS] proposal: EXPLAIN ANALYZE formatting

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

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 (estimatio

Re: [HACKERS] Transactions involving multiple postgres foreign servers

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 fu

[HACKERS] Z-curve spatial index

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 ( http://www.google.com/translate?hl=en&ie=UTF8&sl=auto&tl=en&u=https%3A%2F%2Fhabra

Re: [HACKERS] Microvacuum support for Hash Index

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 >> required to find the r