On 13-04-14 08:06 PM, Steve Singer wrote:
On 13-04-13 04:54 PM, Jeff Janes wrote:
If you are trying to make your own private copy of 9.2, then removing
the fudge factor altogether is probably the way to go. But if you want
to help improve future versions, you probably need to test with the
On 13-04-13 04:54 PM, Jeff Janes wrote:
On Sat, Apr 13, 2013 at 9:14 AM, Steve Singer mailto:ssin...@ca.afilias.info>> wrote:
indexTotalCost += index->pages * spc_random_page_cost / 10.0;
Is driving my high costs on the inner loop. The index has 2-5
million pages dep
On 13-04-12 09:20 PM, Jeff Janes wrote:
On Thursday, April 11, 2013, Steve Singer wrote:
I think the reason why it is picking the hash join based plans is
because of
Index Scan using table_b_1_ptid_orgid_ym_unq on table_b_1 b
(cost=0.00..503.86 rows=1 width=10) (actual time
On 13-04-10 07:54 PM, Steve Singer wrote:
On 13-04-10 02:06 PM, Jeff Janes wrote:
On Wed, Apr 10, 2013 at 6:49 AM, Steve Singer mailto:ssin...@ca.afilias.info>> wrote:
I think the index recheck means your bitmap is overflowing (i.e. needing
more space than work_mem) and so keeping on
On 13-04-10 02:06 PM, Jeff Janes wrote:
On Wed, Apr 10, 2013 at 6:49 AM, Steve Singer mailto:ssin...@ca.afilias.info>> wrote:
I think the index recheck means your bitmap is overflowing (i.e. needing
more space than work_mem) and so keeping only the pages which have at
least one match,
On 13-04-10 09:56 AM, k...@rice.edu wrote:
On Wed, Apr 10, 2013 at 09:49:55AM -0400, Steve Singer wrote:
Hi Steve,
The one thing that stands out to me is that you are working with 200GB of
data on a machine with 4-8GB of ram and you have the random_page_cost set
to 2.0. That is almost
I'm encountering an issue where PG 9.2.4 (we also see this with 9.2.3)
is picking a plan involving a bitmap heap scan that turns out to be much
slower than a nested-loop plan using indexes.
The planner picks the hashjoin plan by default (see attached files)
Bitmap Heap Scan on public.table_b_2
On 10-10-27 02:14 PM, Divakar Singh wrote:
yes this is a very clearly visible problem.
The difference b/w oracle and PG increases with more rows.
when oracle takes 3 GB, PG takes around 6 GB.
I only use varchar.
I will try to use your tips on "smart table layout, toast compression".
Assuming thes
On 10-10-25 02:31 PM, Divakar Singh wrote:
> My questions/scenarios are:
>
> 1. How does PostgreSQL perform when inserting data into an indexed
> (type: btree)
> table? Is it true that as you add the indexes on a table, the
> performance
> deteriorates significantly whereas Oracle does no
