On Sun, Nov 21, 2010 at 9:18 PM, Ivan Voras wrote:
> On 11/22/10 02:47, Kevin Grittner wrote:
>>
>> Ivan Voras wrote:
>>
>>> After 16 clients (which is still good since there are only 12
>>> "real" cores in the system), the performance drops sharply
>>
>> Yet another data point to confirm the imp
On 11/22/10 02:47, Kevin Grittner wrote:
Ivan Voras wrote:
After 16 clients (which is still good since there are only 12
"real" cores in the system), the performance drops sharply
Yet another data point to confirm the importance of connection
pooling. :-)
I agree, connection pooling will
Ivan Voras wrote:
> After 16 clients (which is still good since there are only 12
> "real" cores in the system), the performance drops sharply
Yet another data point to confirm the importance of connection
pooling. :-)
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@p
This is not a request for help but a report, in case it helps developers
or someone in the future. The setup is:
AMD64 machine, 24 GB RAM, 2x6-core Xeon CPU + HTT (24 logical CPUs)
FreeBSD 8.1-stable, AMD64
PostgreSQL 9.0.1, 10 GB shared buffers, using pgbench with a scale
factor of 500 (7.5 GB
Hello
2010/11/21 Humair Mohammed :
> That was a typo:
> work_mem = 2GB
> shared_buffers = 2GB
ok, then try to decrease a shared_buffers. Maybe a win7 has a some
problem - large a shared buffers are well just for UNIX like systems.
I am thinking so 500 MB is enough
Regards
Pavel Stehule
>> From
Excerpts from kuopo's message of dom nov 21 11:15:52 -0300 2010:
> In my experiment, I need about 1~3 min to finish the analyze operation
> on the big table (which depends on the value of vacuum_cost_delay). I
> am not surprised because this table is a really big one (now, it has
> over 200M record
On Nov 21, 2010, at 12:16 PM, Tom Lane wrote:
> t...@fuzzy.cz writes:
>>> Second, I modified the work_mem setting to 2GB (reloaded config) and I see
>>> a response time of 38 seconds. Results below from EXPLAIN ANALYZE:
>
>> How did you reload the config? Using 'kill -HUP pid'? That should work
>
I am running 64-bit Windows 7 Enterprise with 8G RAM and a Dual Core 2.67 Ghz
Intel CPU. Both the SQL 2008 R2 and Postgresql are installed on the same
machine. The DISTINCT FROM instead of the COALESCE does not help much. I ran 2
further tests with work_mem modifications (please note memory usa
1) OS/Configuration64-bit Windows 7 Enterprise with 8G RAM and a Dual Core 2.67
Ghz Intel CPUpostgresql-x64-9.0 (PostgreSQL 9.0.1, compiled by Visual C++ build
1500, 64-bit)work_mem 2GBshared_buffers = 22)
Datasetname,pages,tuples,pg_size_pretty"pivotbad";1870;93496;"15
MB""pivotgood";5025;2
t...@fuzzy.cz writes:
>> Second, I modified the work_mem setting to 2GB (reloaded config) and I see
>> a response time of 38 seconds. Results below from EXPLAIN ANALYZE:
> How did you reload the config? Using 'kill -HUP pid'? That should work
> fine. Have you cheched 'work_mem' after the reload?
> Pavel Stehule wrote:
>> 2010/11/21 Humair Mohammed :
>
>>> shared_buffers = 2
>
>> shared_buffers = 2 ???
>
> Yeah, if that's not a typo, that's a very serious misconfiguration.
I guess that's a typo, as the explain plain in one of the previous posts
contains
Buffers: shared hit=192 read=48
goran wrote:
> Trying to understand why query planer changes the plan from
> effective one to ineffective one when I change the offset in the
> LIMIT. Also, thankfully accepting RTFM pointers to the actual FMs.
The query planner will consider offset and limit clauses when
estimating the cost o
>> 4) INDEXESI can certainly add an index but given the table sizes I am
>> not
>> sure if that is a factor. This by no means is a large dataset less than
>> 350,000 rows in total and 3 columns. Also this was just a quick dump of
>> data for comparison purpose. When I saw the poor performance on th
> First, I modified the work_mem setting to 1GB (reloaded config) from the
> default 1MB and I see a response time of 33 seconds. Results below from
> EXPLAIN ANALYZE:
...
> Second, I modified the work_mem setting to 2GB (reloaded config) and I see
> a response time of 38 seconds. Results below f
Pavel Stehule wrote:
> 2010/11/21 Humair Mohammed :
>> shared_buffers = 2
> shared_buffers = 2 ???
Yeah, if that's not a typo, that's a very serious misconfiguration.
With 8 GB of RAM in the machine, this should probably be set to
somewhere between 200 MB and 2 GB, depending on your workloa
> 4) INDEXESI can certainly add an index but given the table sizes I am not
> sure if that is a factor. This by no means is a large dataset less than
> 350,000 rows in total and 3 columns. Also this was just a quick dump of
> data for comparison purpose. When I saw the poor performance on the
> COA
2010/11/21 Humair Mohammed :
>
> 1) OS/Configuration
> 64-bit Windows 7 Enterprise with 8G RAM and a Dual Core 2.67 Ghz Intel CPU
> postgresql-x64-9.0 (PostgreSQL 9.0.1, compiled by Visual C++ build 1500,
> 64-bit)
> work_mem 2GB
> shared_buffers = 2
shared_buffers = 2 ???
Regards
Pavel Stehule
Trying to understand why query planer changes the plan from effective
one to ineffective one when I change the offset in the LIMIT. Also,
thankfully accepting RTFM pointers to the actual FMs.
Setup is: 3 tables with 0.5M to 1.5M records
While tuning indexes for the following query
SELECT c.id, c.
18 matches
Mail list logo
