On Fri, Oct 15, 2010 at 10:22 PM, Tom Lane wrote:
> Alvaro Herrera writes:
> > If we analyze the parent, do we also update the children stats, or is it
> > just that we keep two stats for the parent, one with children and one
> > without, both being updated when the parent is analyzed?
>
> The l
Alvaro Herrera writes:
> If we analyze the parent, do we also update the children stats, or is it
> just that we keep two stats for the parent, one with children and one
> without, both being updated when the parent is analyzed?
The latter.
The trick here is that we need to fire an analyze on th
Excerpts from Robert Haas's message of mié jun 09 15:47:55 -0400 2010:
> In going back through emails I had marked as possibly needing another
> look before 9.0 is released, I came across this issue again. As I
> understand it, analyze (or analyse) now collects statistics for both
> the parent in
Wouldn't UUID PK cause a significant drop in insert performance because every
insert is now out of order, which leads to a constant re-arranging of the B+
tree? The amount of random IO's that's going to generate would just kill the
performance.
--- On Fri, 10/15/10, Craig Ringer wrote:
From:
Jesper Krogh wrote:
To be honest, if it is EDB, Redpill, Command Prompt, 2nd Quadrant or
whoever end up doing the job is, seen from this perspective not
important, just it ends in the hands of someone "capable" of doing
it. ... although Heikki has done some work on this task already.
Now you're
On 16/10/2010 9:58 AM, Navkirat Singh wrote:
Hi Guys,
I am interested in finding out the pros/cons of using UUID as a primary key
field. My requirement states that UUID would be perfect in my case as I will be
having many small databases which will link up to a global database using the
UUID.
Tatsuo Ishii writes:
> So can I say "if a function is marked IMMUTABLE, then it should never
> modify database"? Is there any counter example?
> It seems if above is correct, I can say STABLE functions should never
> modify databases as well.
Both of those things are explicitly stated here:
http:
Hi Guys,
I am interested in finding out the pros/cons of using UUID as a primary key
field. My requirement states that UUID would be perfect in my case as I will be
having many small databases which will link up to a global database using the
UUID. Hence, the need for a unique key across all da
> broadly speaking:
> *) function generates same output from inputs regardless of what's
> going on in the database, and has no side effects: IMMUTABLE
So can I say "if a function is marked IMMUTABLE, then it should never
modify database"? Is there any counter example?
> *) function reads (only)
On Mon, Oct 11, 2010 at 7:10 PM, Damon Snyder wrote:
> Hello,
> I have heard it said that if a stored procedure is declared as VOLATILE,
> then no good optimizations can be done on queries within the stored
> procedure or queries that use the stored procedure (say as the column in a
> view). I hav
Damon Snyder wrote:
> I have heard it said that if a stored procedure is declared as
> VOLATILE, then no good optimizations can be done on queries within
> the stored procedure or queries that use the stored procedure (say
> as the column in a view). I have seen this in practice, recommended
> o
Very true Igor! Free is my favorite price.
I'll figure a way around this issue.
Thanks for your help.
Tony
On Fri, 2010-10-15 at 14:54 -0400, Igor Neyman wrote:
> > -Original Message-
> > From: Tony Capobianco [mailto:tcapobia...@prospectiv.com]
> > Sent: Friday, October 15, 2010 2:14
> -Original Message-
> From: Tony Capobianco [mailto:tcapobia...@prospectiv.com]
> Sent: Friday, October 15, 2010 2:14 PM
> To: pgsql-performance@postgresql.org
> Subject: Re: oracle to psql migration - slow query in postgres
>
> Thanks for all your responses. What's interesting is that
Brandon Casci writes:
> I have an application hosted on Heroku. They use postgres. It's more or less
> abstracted away, but I can get some performance data from New Relic. For the
> most part, performance is ok, but now and then some queries take a few
> seconds, and spike up to 15 or even 16 seco
Nikolai Zhubr writes:
> So, "in (1, 2)" condition is not in Index Cond anymore! Why is that? How
> can I push it back?
It thinks the indexscan condition is sufficiently selective already.
An = ANY condition like that will force multiple index searches,
one for each of the OR'd possibilities, so
Thanks for all your responses. What's interesting is that an index is
used when this query is executed in Oracle. It appears to do some
parallel processing:
SQL> set line 200
delete from plan_table;
explain plan for
select websiteid, emailaddress
from members
where emailok = 1
and emailboun
> -Original Message-
> From: Tony Capobianco [mailto:tcapobia...@prospectiv.com]
> Sent: Thursday, October 14, 2010 3:43 PM
> To: pgsql-performance@postgresql.org
> Subject: oracle to psql migration - slow query in postgres
>
> We are in the process of testing migration of our oracle d
Neil Whelchel wrote:
That is why I suggested an estimate(*) that works like (a faster) count(*)
except that it may be off a bit. I think that is what he was talking about
when he wrote this.
The main problem with "select count(*)" is that it gets seriously
mis-used. Using "select count
Hello
I have an application hosted on Heroku. They use postgres. It's more or less
abstracted away, but I can get some performance data from New Relic. For the
most part, performance is ok, but now and then some queries take a few
seconds, and spike up to 15 or even 16 seconds! Ouch!
This is the
Thanks for fixing the docs, but if that's the case, I shouldn't be
seeing the behavior that I'm seeing.
Should I flesh out this test case a little better and file a bug?
Thanks,
Joe
On Tue, Sep 21, 2010 at 4:44 PM, Tom Lane wrote:
> Joe Miller writes:
>> I was looking at the autovacuum docum
Hello people,
I'm having trouble to persuade index scan to check all of the conditions
I specify _inside_ index cond. That is, _some_ condition always get
pushed out of index cond and applied later (which will often result, for
my real table contents, in too many unwanted rows initially hit by
Hello
I have an application hosted on Heroku. They use postgres. It's more or less
abstracted away, but I can get some performance data from New Relic. For the
most part, performance is ok, but now and then some queries take a few
seconds, and spike up to 15 or even 16 seconds! Ouch!
This is the
Jon Nelson wrote:
Well, I didn't quite mean that - having no familiarity with Oracle I
don't know what the alter system statement does, but I was talking
specifically about the linux buffer and page cache.
Those are not utilized by Oracle. This is a RAC instance, running on
top of ASM, w
Hello,
I have heard it said that if a stored procedure is declared as VOLATILE,
then no good optimizations can be done on queries within the stored
procedure or queries that use the stored procedure (say as the column in a
view). I have seen this in practice, recommended on the irc channel, and in
>> This table has approximately 300million rows.
>
> and your query grab rows=236 660 930 of them. An index might be
> useless in this situation.
I want to point out that this is probably the most important comment
here. A couple of people have noted out that the index won't work for
this query, b
The recommendations on the numeric columns are fantastic. Thank you
very much. We will revisit our methods of assigning datatypes when we
migrate our data over from Oracle.
Regarding the full table scans; it appears inevitable that full table
scans are necessary for the volume of data involved an
On Thu, Oct 14, 2010 at 3:43 PM, Tony Capobianco
wrote:
> explain analyze create table tmp_srcmem_emws1
> as
> select emailaddress, websiteid
> from members
> where emailok = 1
> and emailbounced = 0;
*) as others have noted, none of your indexes will back this
expression. For an index to ma
Samuel Gendler wrote:
On Thu, Oct 14, 2010 at 8:59 PM, Mladen Gogala
mailto:mladen.gog...@vmsinfo.com>> wrote:
If working with partitioning, be very aware that PostgreSQL
optimizer has certain problems with partitions, especially with
group functions. If you want speed, everythi
On Wed, 2010-10-13 at 09:02 -0400, Greg Smith wrote:
> XFS support is available as an optional module starting in RHEL 5.5.
> In CentOS, you just grab it, so that's what I've been doing. My
> understanding is that you may have to ask your sales rep to enable
> access to it under the official Re
On Thu, Oct 14, 2010 at 8:59 PM, Mladen Gogala wrote:
> If working with partitioning, be very aware that PostgreSQL optimizer has
> certain problems with partitions, especially with group functions. If you
> want speed, everything must be prefixed with partitioning column: indexes,
> expressions,
30 matches
Mail list logo
