[HACKERS] bitmap scan much slower than index scan, hash_search_with_hash_value

2012-09-01 Thread Sergey Koposov
Hi, I'm experiencing the case when bitmap scan is ~ 70 times slower than index scan which seems to be caused by 1) very big table 2) some hash search logic (hash_search_with_hash_value ) Here is the explain analyze of the query with bitmap scans allowed: wsdb=> explain analyze select * from

[HACKERS] Fwd: PATCH: psql boolean display

2012-09-01 Thread Pavel Stehule
-- Forwarded message -- From: Pavel Stehule Date: 2012/9/1 Subject: PATCH: psql boolean display To: Phil Sorber Hello I am looking to your patch: I have only one note. I don't think so using any text for values "true" and "false" is good idea. I don't see a sense of any specia

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Robert Haas
On Sat, Sep 1, 2012 at 11:45 AM, Bruce Momjian wrote: > On Mon, Aug 13, 2012 at 12:46:43PM +0200, Magnus Hagander wrote: >> On Mon, Aug 13, 2012 at 4:34 AM, Tom Lane wrote: >> > I've been experimenting with moving the Unix socket directory to >> > /var/run/postgresql for the Fedora distribution (

Re: [HACKERS] Getting rid of cheap-startup-cost paths earlier

2012-09-01 Thread Bruce Momjian
On Sat, Sep 1, 2012 at 06:23:59PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Tue, May 22, 2012 at 1:50 AM, Tom Lane wrote: > >> Currently, the planner keeps paths that appear to win on the grounds of > >> either cheapest startup cost or cheapest total cost. It suddenly struck > >> me t

Re: [HACKERS] Getting rid of cheap-startup-cost paths earlier

2012-09-01 Thread Tom Lane
Robert Haas writes: > On Tue, May 22, 2012 at 1:50 AM, Tom Lane wrote: >> Currently, the planner keeps paths that appear to win on the grounds of >> either cheapest startup cost or cheapest total cost. It suddenly struck >> me that in many simple cases (viz, those with no LIMIT, EXISTS, cursor >

Re: [HACKERS] [GENERAL] Date conversion using day of week

2012-09-01 Thread Bruce Momjian
[Properly posted to hackers list] On Fri, Apr 1, 2011 at 02:27:02AM +1100, Brendan Jurd wrote: > On 1 April 2011 02:00, Adrian Klaver wrote: > > On Wednesday, March 30, 2011 8:39:25 pm Brendan Jurd wrote: > >> If we wanted to make it "work", then I think the thing to do would be > >> to add a ne

Re: [HACKERS] too much pgbench init output

2012-09-01 Thread Tomas Vondra
On 1 Září 2012, 12:30, Robert Haas wrote: > On Sat, Sep 1, 2012 at 12:00 AM, Peter Eisentraut wrote: >> When initializing a large database, pgbench writes tons of "%d tuples >> done" lines. I propose to change this to a sort of progress counter >> that stays on the same line, as in the attached p

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Bruce Momjian
On Sat, Sep 1, 2012 at 03:05:01PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > My point is that we are still going to need traditional connections for > > live checks. > > Yes, but that's not terribly relevant, IMO. All it means is that we > don't want to invent some solution that doesn't

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Bruce Momjian
On Sat, Sep 1, 2012 at 03:06:57PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Sat, Sep 1, 2012 at 02:43:35PM -0400, Tom Lane wrote: > >> I'm inclined to think that the "no sockdir" case is broken and you > >> should get rid of it. If you're starting a postmaster, you can and > >> shou

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Tom Lane
Bruce Momjian writes: > On Sat, Sep 1, 2012 at 02:43:35PM -0400, Tom Lane wrote: >> I'm inclined to think that the "no sockdir" case is broken and you >> should get rid of it. If you're starting a postmaster, you can and >> should tell it a sockdir, period. If you're running a live check this >

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Tom Lane
Bruce Momjian writes: > My point is that we are still going to need traditional connections for > live checks. Yes, but that's not terribly relevant, IMO. All it means is that we don't want to invent some solution that doesn't go through libpq. > If we could find a solution for Windows, the soc

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Bruce Momjian
On Sat, Sep 1, 2012 at 02:43:35PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Well, you only want the unix_socket* if sockdir is defined, but you want > > LISTEN_STR unconditionally, even if there is no sockdir. > > Really? What will happen when the installation's default is to not > lis

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Bruce Momjian
On Sat, Sep 1, 2012 at 02:18:59PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Sat, Sep 1, 2012 at 11:45:58AM -0400, Bruce Momjian wrote: > >> So, in summary, this patch moves the socket directory to the current > >> directory all but live check operation, and handles different socket >

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Tom Lane
Bruce Momjian writes: > Well, you only want the unix_socket* if sockdir is defined, but you want > LISTEN_STR unconditionally, even if there is no sockdir. Really? What will happen when the installation's default is to not listen on any Unix socket? (unix_socket_directories = '' in postgresql.c

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Bruce Momjian
On Sat, Sep 1, 2012 at 02:23:22PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > + /* > > +* Report the Unix domain socket directory location to the > > postmaster. > > +*/ > > "Report" seems entirely the wrong verb there. > > > + #define LISTEN_STR" -c listen_addres

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Tom Lane
Bruce Momjian writes: > + /* > + * Report the Unix domain socket directory location to the > postmaster. > + */ "Report" seems entirely the wrong verb there. > + #define LISTEN_STR " -c listen_addresses=''" > + > + /* Have a sockdir to use? */ > + if (strlen(os_info

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Tom Lane
Bruce Momjian writes: > On Sat, Sep 1, 2012 at 11:45:58AM -0400, Bruce Momjian wrote: >> So, in summary, this patch moves the socket directory to the current >> directory all but live check operation, and handles different socket >> directories for old cluster >= 9.1. I have added a documentatio

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Bruce Momjian
On Sat, Sep 1, 2012 at 11:45:58AM -0400, Bruce Momjian wrote: > So, in summary, this patch moves the socket directory to the current > directory all but live check operation, and handles different socket > directories for old cluster >= 9.1. I have added a documentation > mention of how to make t

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-09-01 Thread Bruce Momjian
On Mon, Aug 13, 2012 at 12:46:43PM +0200, Magnus Hagander wrote: > On Mon, Aug 13, 2012 at 4:34 AM, Tom Lane wrote: > > I've been experimenting with moving the Unix socket directory to > > /var/run/postgresql for the Fedora distribution (don't ask :-(). > > It's mostly working, but I found out yet

[HACKERS] Re: [COMMITTERS] pgsql: Cross-link to doc build requirements from install requirements.

2012-09-01 Thread Stefan Kaltenbrunner
On 09/01/2012 12:28 PM, Robert Haas wrote: > Cross-link to doc build requirements from install requirements. > > Jeff Janes > > Branch > -- > master > > Details > --- > http://git.postgresql.org/pg/commitdiff/e8d6c98c2f082bead1202b23e9d70e0fbde49129 > > Modified Files > -- >

Re: [HACKERS] too much pgbench init output

2012-09-01 Thread Robert Haas
On Sat, Sep 1, 2012 at 12:00 AM, Peter Eisentraut wrote: > When initializing a large database, pgbench writes tons of "%d tuples > done" lines. I propose to change this to a sort of progress counter > that stays on the same line, as in the attached patch. I'm not sure I like this - what if the o

Re: [HACKERS] 9.2rc1 build requirements

2012-09-01 Thread Robert Haas
On Thu, Aug 30, 2012 at 8:31 PM, Jeff Janes wrote: > patch to do that attached. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: ht