Also are a.indexid and b.indexid the same type?
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Sun, Aug 22, 2010 at 10:23 PM, Jann Röder wrote:
> I have two tables:
> A: ItemID (PK), IsssueID (Indexed)
> B: ItemID (FK), IndexNumber : PK(ItemID, IndexNumber)
>
> Both tables have several million columns, but B has much more than A.
>
> Now if I run
>
> SELECT A.ItemID FROM A, B WHERE A.Ite
I have two tables:
A: ItemID (PK), IsssueID (Indexed)
B: ItemID (FK), IndexNumber : PK(ItemID, IndexNumber)
Both tables have several million columns, but B has much more than A.
Now if I run
SELECT A.ItemID FROM A, B WHERE A.ItemID = B.itemID AND A.issueID =
The query takes extremely long (sev
Alexandre de Arruda Paes wrote:
Unfortunately, the customer can't wait for the solution and the
programmer eliminated the
use of this table by using a in-memory array.
Well that will be fun. Now they've traded their old problem for a new
one--cache inconsistency between the data in memory an
Dimitri wrote:
I understand well that it's respecting the standard and so on, but the
background problem that you may see your table bloated just because
there is a long running transaction appeared in another database, and
if it's maintained/used/etc by another team - the problem very quickly
ma
The problem here is that we're trying to keep an image of a whole
world for any transaction which is in most cases will need to get a
look on few streets around.. ;-)
I understand well that it's respecting the standard and so on, but the
background problem that you may see your table bloated just b
On Sat, Aug 21, 2010 at 9:49 AM, Alexandre de Arruda Paes
wrote:
> Only for discussion: the CLUSTER command, in my little knowledge, is a
> intrusive command that's cannot recover the dead tuples too.
>
> Only TRUNCATE can do this job, but obviously is not applicable all the time.
Either VACUUM o
