Re: [PERFORM] Weird, bad 0.5% selectivity estimate for a column equal to itself

2013-06-25 Thread Tom Lane
Josh Berkus writes: >> Personally, I'll bet lunch that that external software is outright >> broken, ie it probably thinks "X = X" is constant true and they found >> they could save two lines of code and a few machine cycles by emitting >> that rather than not emitting anything. > Well, it was mo

Re: [PERFORM] incorrect row estimates for primary key join

2013-06-25 Thread Ben
On Jun 25, 2013, at 4:36 PM, Tom Lane wrote: >> That seems intuitive, but some of the estimates need to be made >> before all such information is available. Maybe we can do >> something about that some day >> Maybe someone else will jump in here with more details than I can >> provide (at le

Re: [PERFORM] incorrect row estimates for primary key join

2013-06-25 Thread Tom Lane
Kevin Grittner writes: > Ben wrote: >> it seems to me that an equality join between two relations (call them A and >> B) >> using columns in relation B with a unique constraint should yield row >> estimates >> which are at most equal to the row estimates for relation A.  my questions >> are >>

Re: [PERFORM] Weird, bad 0.5% selectivity estimate for a column equal to itself

2013-06-25 Thread Josh Berkus
> Personally, I'll bet lunch that that external software is outright > broken, ie it probably thinks "X = X" is constant true and they found > they could save two lines of code and a few machine cycles by emitting > that rather than not emitting anything. Of course, the amount of > parsing/planni

Re: [PERFORM] incorrect row estimates for primary key join

2013-06-25 Thread Kevin Grittner
Ben wrote: > it seems to me that an equality join between two relations (call them A and B) > using columns in relation B with a unique constraint should yield row > estimates > which are at most equal to the row estimates for relation A.  my questions are > > 1 - is this correct? > > 2 - does t

Re: [PERFORM] incorrect row estimates for primary key join

2013-06-25 Thread Ben
hello -- thanks kevin for the tuning advice, i will answer your questions below and try different tuning configurations and report back. but first allow me take a step back and ask a couple simple questions : it seems to me that an equality join between two relations (call them A and B) using

Re: [PERFORM] incorrect row estimates for primary key join

2013-06-25 Thread Julien Cigar
On 06/25/2013 00:18, Ben wrote: hello postgresql experts -- i have a strange row estimate problem, which unfortunately i have trouble reproducing for anything but very large tables which makes boiling down to a simple example hard. i'm using version 9.1.1, all tables have had analyze run on

Re: [PERFORM] incorrect row estimates for primary key join

2013-06-25 Thread Kevin Grittner
Ben wrote: > PostgreSQL 9.1.1 on x86_64-suse-linux-gnu, compiled by gcc (SUSE Linux) > 4.6.2, 64-bit Consider applying the latest bug fixes for 9.1 -- which would leave you showing 9.1.9. http://www.postgresql.org/support/versioning/ > default_statistics_target    | 50    | config

Re: [PERFORM] PHP Postgres query slower then PgAdmin

2013-06-25 Thread Emrah Mehmedov
On Mon, Jun 24, 2013 at 12:04 PM, Marcin Mańk wrote: > On Mon, Jun 24, 2013 at 11:55 AM, Emrah Mehmedov > wrote: > > Marcin: This heppens everytime when i try to query different keyword in > FTS > > for example: > > > > firsttime: query: "Hello & World" 15sec~ > > secondtime: query: "Hello & Wor

Re: [PERFORM] on disk and in memory

2013-06-25 Thread Albe Laurenz
Jayadevan M wrote: > If a table takes 100 MB while on disk, approximately how much space will it > take in RAM/database > buffer? 100 MB. A block in memory has the same layout as a block on disk. Yours, Laurenz Albe -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)