Re: Query performance going from Oracle to Postgres

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: "Dirschel, Steve" <steve(dot)dirschel(at)thomsonreuters(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, "Wong, Kam Fook (TR Technology)" <kamfook(dot)wong(at)thomsonreuters(dot)com>
Subject: Re: Query performance going from Oracle to Postgres
Date: 2023-09-07 10:48:06
Message-ID: CAApHDvrR18bk9qkfBpcAnFRpp5JZ0C0=iVXkOxAxD+aWwk8LEQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 7 Sept 2023 at 19:17, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> It seems likely that the problem here is that some of the predicates
> appear as so-called "Filter:" conditions, as opposed to true index
> quals.

hmm, if that were true we'd see "Rows Removed by Filter" in the
explain analyze.

I think all that's going on is that each tuple is on a different page
and the heap accesses are just causing many buffers to be accessed. It
seems to me that an IOS would likely fix that problem which is why I
suggested count(*) instead of
count(<not_null_column_thats_the_only_col_used_thats_not_in_the_index>)

David

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joe Conway 2023-09-07 12:44:37 Re: postgreSQL UPPER Method is converting the character "µ" into "M"
Previous Message gzh 2023-09-07 07:45:06 ERROR: stack depth limit exceeded