Unless you use the explicit join syntax:
select p.* from A p join B q on (p.id = q.id)
and also set join_collapse_limit= 1
The order of the joins is determined by the planner.
Also explain is your friend :)
From: Adarsh Sharma
To: pgsql-performance@postgresq
No: The commit has the same guarantees as a synchronous commit w.r.t. data
consistency. The commit can only fail (as a whole) due to hardware problems or
postgres backend crashes.
And yes: The client commit returns, but the server can fail later and not
persist the transaction and it will be
On Sat, Jul 30, 2011 at 8:10 AM, Robert Klemme
wrote:
> On Thu, Jul 28, 2011 at 11:00 PM, Li Jin wrote:
>> I met with the problem that when I was using WITH clause to reuse a
>> subquery, I got a huge performance penalty because of query planner.
>> Here are the details, the original query is
>>
Robert Ayrapetyan wrote:
> So I'm still convinced - this bug relates to FreeBSD 64-bit + UFS
> + bigint column index
> (some of these may be superfluous, but I have no resources to
> check on different platforms with different filesystems).
Linux 64 bit XFS bigint column index only shows a sli
Hi Tom,
> > I'm looking for a hint how array access performs in PostgreSQL in
> > respect to performance. Normally I would expect access of a
> > 1-dimensional Array at slot i (array[i]) to perform in constant time
> > (random access).
>
> > Is this also true for postgres' arrays?
>
> Only if th
Andreas Brandl writes:
> I'm looking for a hint how array access performs in PostgreSQL in respect to
> performance. Normally I would expect access of a 1-dimensional Array at slot
> i (array[i]) to perform in constant time (random access).
> Is this also true for postgres' arrays?
Only if the
On 01/08/11 19:18, Robert Klemme wrote:
On Sat, Jul 30, 2011 at 3:01 AM, Gavin Flower
wrote:
On 24/07/11 03:58, alan wrote:
My first approach would be to remove WeekAvg and MonthAvg from the
table and create a view which calculates appropriate values.
Thanks Robert, I had to upgrade to 9.0.4
Seems this assumption is not right. Just created simple index on
bigint column - situation with huge performance
degradation repeated. Dropping this index solved COPY issues on the fly.
So I'm still convinced - this bug relates to FreeBSD 64-bit + UFS +
bigint column index
(some of these may be sup
Quite possible.
But anyway - I don't think performance degradation must be so huge in
case of using UNIQUE indexes.
On Mon, Aug 1, 2011 at 12:06 PM, Vitalii Tymchyshyn wrote:
> 31.07.11 16:51, Robert Ayrapetyan написав(ла):
>>
>> Hello.
>>
>> I've found strange behavior of my pg installation (tes
> Is this also true for postgres' arrays?
Sorry, I'm using latest postgres 9.0.4 on debian squeeze/amd64.
Greetings
Andreas
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Hi,
I'm looking for a hint how array access performs in PostgreSQL in respect to
performance. Normally I would expect access of a 1-dimensional Array at slot i
(array[i]) to perform in constant time (random access).
Is this also true for postgres' arrays?
May concrete example is a 1-dimensiona
Hello everyone,
This is my first post on this list, I tried to look after possible solutions in
the archive, as well as in google, but I could not find an explanation for such
a specific situation.
I am facing a performance problem connected with Postgres Tsearch2 FTS
mechanism.
Here is my qu
02.08.11 11:26, Robert Ayrapetyan написав(ла):
Seems this assumption is not right. Just created simple index on
bigint column - situation with huge performance
degradation repeated. Dropping this index solved COPY issues on the fly.
So I'm still convinced - this bug relates to FreeBSD 64-bit + UF
13 matches
Mail list logo
