Hi,
On 12 October 2012 15:14, Korisk wrote:
> Strange situation.
> After indexscan enabling the cost is seriously decreased.
You can not really disable any scan method. enable_xxx = off just sets
very high cost (=100) for that operation.
--
Ondrej Ivanic
(ondrej.iva...@gmail.com)
(http
Strange situation.
After indexscan enabling the cost is seriously decreased.
hashes=# set enable_bitmapscan=on;
SET
hashes=# explain analyse verbose select name, count(name) as cnt from
hashcheck group by name order by name desc;
On Thu, Oct 11, 2012 at 8:55 PM, Korisk wrote:
> hashes=# explain analyse verbose select name, count(name) as cnt from
> hashcheck group by name order by name desc;
Now set enable_bitmapscan and enable_indexscan to on an try it again.
Then set enable_seqscan to on and run it one more time.
>
Again the same cost.
hashes=# SELECT name, setting, reset_val FROM pg_settings WHERE setting <>
reset_val;
name |setting | reset_val
-++---
archive_command | (disabled) |
enable_bitmapscan | off
On Wed, Oct 10, 2012 at 10:42 PM, Scott Marlowe wrote:
> I think the query planner has gotten a little smarter of late:
>
> smarlowe=# create index on a (i) where i is not null;
> CREATE INDEX
> smarlowe=# explain select * from a where i =10;
>QUERY PLAN
> -
On 10/11/2012 05:46 PM, Sergio Gabriel Rodriguez wrote:
Hi,
I tried with Postgresql 9.2 and the process used to take almost a
day and a half, was significantly reduced to 6 hours, before failing
even used to take four hours. My question now is, how long should it
take the backup for a 200GB
Sergio Gabriel Rodriguez writes:
> I tried with Postgresql 9.2 and the process used to take almost a day
> and a half, was significantly reduced to 6 hours, before failing even used
> to take four hours. My question now is, how long should it take the backup
> for a 200GB database with 80% of
Hi,
I tried with Postgresql 9.2 and the process used to take almost a day
and a half, was significantly reduced to 6 hours, before failing even used
to take four hours. My question now is, how long should it take the backup
for a 200GB database with 80% of large objects?
Hp proliant Xeon G5
32
Jeff,
> Does anyone see effective_cache_size make a difference anyway? If so,
> in what circumstances?
E_C_S, together with random_page_cost, the table and index sizes, the
row estimates and the cpu_* costs, form an equation which estimates the
cost of doing various kinds of scans, particularly
On Thu, Oct 11, 2012 at 8:15 AM, Korisk wrote:
> What's your seq_page_cost and random_page_cost?
> hashes=# SELECT name, setting, reset_val FROM pg_settings WHERE setting <>
> reset_val;
> name |setting | reset_val
> -++-
"IOS scan" ?
Index Only Scan
What's your seq_page_cost and random_page_cost?
hashes=# SELECT name, setting, reset_val FROM pg_settings WHERE setting <>
reset_val;
name |setting | reset_val
-++---
archive_command
On 10/11/2012 04:19 PM, Claudio Freire wrote:
On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani wrote:
sorry to come late to the party, but being in a similar condition
I've googled a bit and I've found a way to disable hyperthreading without
the need to reboot the system and entering the bios:
On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani wrote:
> sorry to come late to the party, but being in a similar condition
> I've googled a bit and I've found a way to disable hyperthreading without
> the need to reboot the system and entering the bios:
>
> echo 0 >/sys/devices/system/node/node0/
On 10/09/2012 01:40 AM, Craig James wrote:
Nobody has commented on the hyperthreading question yet ... does it really
matter? The old (fast) server has hyperthreading disabled, and the new (slower)
server has hyperthreads enabled.
If hyperthreading is definitely NOT an issue, it will save me a
Le 11/10/2012 07:26, Craig Ringer a écrit :
* The partial index will only be used for queries that use the
condition "WHERE col IS NOT NULL" themselves. The planner isn't
super-smart about how it matches index WHERE conditions to query WHERE
conditions, so you'll want to use exactly the same co
15 matches
Mail list logo
