I have a query which does not use column indexes that it should use. I
have discovered some interesting behaviors of Postgres which may
indicate a bug in the database's query planning.
Take a look at the query below. There is a btree index on both
m.account_id and a.account_id. Query (1)
On Dec 21, 2003, at 11:47 PM, Tom Lane wrote:
"Steven D.Arnold" <[EMAIL PROTECTED]> writes:
Query (2) below is the same query, but we reverse the order of the
tables. It's obviously not quite the same query semantically, even
though in my case it should always produce the
Thanks to all for the detailed replies. I just wanted to let everyone
know -- for future google searches as much as anything else -- that
dumping the database, upgrading to 7.4.1 and reloading did solve the
problem. All the queries I mentioned now use the available indices,
except for underst
How good is Postgres' performance for massive simultaneous insertions
into the same heavily-indexed table? Are there any studies or
benchmarks I can look at for that?
I understand Postgres uses MVCC rather than conventional locking, which
makes it easier to do parallel inserts. In my environm
