Hi, Tom,
Tom Lane wrote:
> You're wrong. An UPDATE always writes a new version of the row (if it
> overwrote the row in-place, it wouldn't be rollback-able). The new
> version has a different TID and therefore the index entry must change.
> To support MVCC, our approach is to always insert a ne
Markus,
Thank you for your kind explanation.
Peter
Markus Schaber wrote:
Hi, Peter,
Péter Kovács wrote:
Sorry for the amateurish question, but what are "heap tuples"?
Also, my understanding is that the following statement applies only for
composite indexes: "PostgreSQL can't use the valu
Markus Schaber <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Actually, when the UPDATE puts a new row version in the same heap page,
>> the index must be updated anyway.
> AFAICS only, when the index covers (directly or via function) a column
> that's actually changed.
> Changing columns
Hi, Alvaro,
Alvaro Herrera wrote:
>> Additionally, in most UPDATE cases, the new row version will fit into
>> the same page as the old version. In this case, the index does not have
>> to be changed, which is an additional speed improvement.
> Actually, when the UPDATE puts a new row version in t
Markus Schaber wrote:
> Additionally, in most UPDATE cases, the new row version will fit into
> the same page as the old version. In this case, the index does not have
> to be changed, which is an additional speed improvement.
Actually, when the UPDATE puts a new row version in the same heap page
Hi, Peter,
Péter Kovács wrote:
> Sorry for the amateurish question, but what are "heap tuples"?
>
> Also, my understanding is that the following statement applies only for
> composite indexes: "PostgreSQL can't use the values stored in the index
> to check the join condition". I assume that Postg
Sorry for the amateurish question, but what are "heap tuples"?
Also, my understanding is that the following statement applies only for
composite indexes: "PostgreSQL can't use the values stored in the index
to check the join condition". I assume that PostgreSQL will be able to
use single-colum
Tom Lane a écrit :
Arnaud Lesauvage <[EMAIL PROTECTED]> writes:
When I join these two tables, the 2-column index of the first table is
not used.
Why does the query planner think that this plan is better ?
Hm, is gid by itself nearly unique in these tables? If so, the merge
join would get on
Arnaud Lesauvage <[EMAIL PROTECTED]> writes:
> When I join these two tables, the 2-column index of the first table is
> not used.
> Why does the query planner think that this plan is better ?
Hm, is gid by itself nearly unique in these tables? If so, the merge
join would get only marginally mor
Heikki Linnakangas a écrit :
Arnaud Lesauvage wrote:
It is quite typical, yes. It is the base query of a view. In fact, most
views have a lot more joins (they join with all the upper-level tables).
But 150ms is OK, indeed.
If the query using the view does anything more than a "SELECT * FROM
Arnaud Lesauvage wrote:
It is quite typical, yes. It is the base query of a view. In fact, most
views have a lot more joins (they join with all the upper-level tables).
But 150ms is OK, indeed.
If the query using the view does anything more than a "SELECT * FROM
view", you should do an explai
Heikki Linnakangas a écrit :
Arnaud Lesauvage wrote:
This query was taken from my "adminsitrative areas" model (continents,
countries, etc...). Whenever I query this model, I have to join many
tables.
I don't really know what the overhead of reading the heap-tuples is, but
would it be a good i
Arnaud Lesauvage wrote:
I did not know that joins were not using index values, and that
PostgreSQL had to fecth the heap tuples anyway.
Does this mean that this 2-column index is useless ? (I created it for
the join, I don't often filter on both columns otherwise)
Well, if no-one is using the
Heikki Linnakangas a écrit :
Arnaud Lesauvage wrote:
I have two table with a 2-column index on both of them.
In the first table, the first colum of the index is the primary key, the
second one is an integer field.
In the second table, the two columns are the primary key.
When I join these two
Arnaud Lesauvage wrote:
I have two table with a 2-column index on both of them.
In the first table, the first colum of the index is the primary key, the
second one is an integer field.
In the second table, the two columns are the primary key.
When I join these two tables, the 2-column index of
15 matches
Mail list logo
