I am currently looking at a performance issue where a subquery is
executed even though I cannot see the result ever being asked for or
used. Not even google has helped me find any information about this one.
I have created a simple test case to demonstrate this.
CREATE TABLE test1 (t1 INT);
IN
Thanks Julien very much.
Two strange behaviors I found:
1) Even I restart the machine and restart the PostgreSQL, then I execute
the query, i still see the shared_hit. It seems when start PG, i will
automatically load the data in the cache of the last time?
2) After I rerun the query, the time for
<>
Technically, yes. That would really help, but the issue is scheduling.
Although the logs are closed off for writes, they aren't closed off for
reads, ref PG documentation: "When a table is being clustered, an ACCESS
EXCLUSIVE lock is acquired on it. This prevents any other database
operatio
Vahe Evoyan writes:
> Merge Join (cost=0.00..2513.96 rows=1 width=72) (actual
> time=127.361..473.687 rows=66460 loops=1)
>Merge Cond: ((v1.dft_id = v2.dft_id) AND ((v1.key)::text =
> (v2.key)::text))
>-> Index Scan using qor_value_self_join on qor_value v1
> (cost=0.00..1255.60 rows=27
On Fri, Feb 22, 2013 at 3:21 AM, Davide Berra wrote:
> I got a problem with the performance of a PL/PGsql stored procedure
> outputting an xml.
>
> Server version: PostgreSQL 8.3.6 on i686-pc-linux-gnu, compiled by GCC gcc
> (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)
> CPU: Intel(R) Core(TM) i3 CPU 5
On Wed, Feb 27, 2013 at 3:15 AM, Costin Oproiu wrote:
> I took some time to figure out a reasonable tuning for my fresh 9.2.3
> installation when I've noticed the following:
>
> [costin@fsr costin]$ /home/pgsql/bin/pgbench -h 192.1.1.2 -p 5432 -U
> postgres -i -s 1
> ...
> 10 tuples done.
> ..
> From: Josh Berkus
>To: Scott Marlowe
>Cc: pgsql-performance@postgresql.org
>Sent: Thursday, 21 February 2013, 3:14
>Subject: Re: [PERFORM] High CPU usage / load average after upgrading to Ubuntu
>12.04
>
>
>> Sounds to me like your IO system is stalling on fsyncs or something
>> like that.
>Rebuilding the index might help, as it would put all the leaf pages holding
>values for session_id=27 adjacent to each other, so they would read from disk
>faster. But with a name like >"session_id", I don't know how long such
>clustering would last though.
>If I'm right about the index disk
I have a planner problem that looks like a bug, but I'm not familiar enough
with how planner the works to say for sure.
This is my schema:
create table comments (
id serial primary key,
conversation_id integer,
created_at timestamp
);
create index comments_conversat
I got a problem with the performance of a PL/PGsql stored procedure
outputting an xml.
/Server version:/ PostgreSQL 8.3.6 on i686-pc-linux-gnu, compiled by GCC
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)
/CPU/: Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz
/RAM installed:/ 4GB
/Hard Disk:/ Seagate 5
I'm trying to create a view that uses a window function, but it seems that
Postgres is apparently unable to optimize it. Here's a reproduction of my
situation with 9.2.2:
---
drop table if exists values cascade; create table values ( fkey1 integer
not null, fkey2 integer not null, fkey3 integer n
On 23/02/13 08:05, Nikolas Everett wrote:
I can't really help, but I can make it more clear why postgres is
choosing a _bitmap_ index scan rather than a regular index scan. With
a regular index scan it pumps the index for the locations of the rows
that it points to and loads those rows as it f
I took some time to figure out a reasonable tuning for my fresh 9.2.3
installation when I've noticed the following:
[costin@fsr costin]$ /home/pgsql/bin/pgbench -h 192.1.1.2 -p 5432 -U
postgres -i -s 1
...
10 tuples done.
...
vacuum...done.
[costin@fsr costin]$ /home/pgsql/bin/pgbench -h 192.1
Hello,
The Query Plan for the query below shows a large number in its actual rows
count by an unknown reason. As a result Merge Join works on a large enough
data to slow down the query.
The table which I query has the following description:
On Wed, Feb 20, 2013 at 3:44 PM, Josh Berkus wrote:
> On 02/19/2013 07:15 PM, Scott Marlowe wrote:
>> On Tue, Feb 19, 2013 at 4:24 PM, Josh Berkus wrote:
>>> ... then you'll see checkpoint "stalls" and spread checkpoint will
>>> actually make them worse by making the stalls longer.
>>
>> Wait, if
I get it now... project_id=115 has a frequency of 0.09241 in pg_stats.
So if ((project_id = 115) AND (project_id = 115)) is considered as two
independent conditions, the row estimate ends up being 0.09241 *
0.09241 * 1.20163e+07 (reltuples from pg_class) = 102614.
http://www.postgresql.org/docs/9.
On 02/28/2013 16:11, Ao Jianwang wrote:
Hi,
Does any one can tell me why the same query runs against on smaller
data is slower than bigger table. thanks very much.
I am using PostgreSQL9.1.8.
*t_apps_1 and t_estimate_1 are about 300M respectively, while *_list_1
about 10M more or less. Acco
Hi,
Does any one can tell me why the same query runs against on smaller data is
slower than bigger table. thanks very much.
I am using PostgreSQL9.1.8.
*t_apps_1 and t_estimate_1 are about 300M respectively, while *_list_1
about 10M more or less. According to the result, it need to read a lot of
18 matches
Mail list logo
