# PERFORMANCE ANALYSIS: Slow "Rent" (Renta) Filter

## Current Indexes on Property Table
Based on schema.prisma analysis:
- @@unique([clientId, tokkoId])
- @@unique([clientId, inmoappId])
- @@index([externalTokkoId])
- @@index([clientId, source])
- @@index([clientId, isPublished])

**MISSING INDEX**: operationType

## Query Analysis

### GET /api/properties endpoint (backend/src/routes/properties.js:167-236)

The endpoint builds a WHERE clause with:
- clientId (from filterByClient middleware)
- operationType (from query param, e.g., "Rent")
- Additional filters: propertyType, source, isPublished, isExclusive, priority

### The Slow Query
When user selects "Rent" filter, the Prisma query is:

```javascript
const properties = await prisma.property.findMany({
  where: {
    clientId: "xyz",      // Index: @@index([clientId, source]) or [clientId, isPublished]
    operationType: "Rent" // NO INDEX - FULL TABLE SCAN!
  },
  include: {
    images: { orderBy: { order: 'asc' }, take: 1 },
    driveFolders: { orderBy: { order: 'asc' } },
    shortUrls: { where: { contentId: null }, orderBy: { createdAt: 'desc' }, take: 1 },
    _count: { select: { contents: true } }
  },
  orderBy: [
    { priority: 'asc' },
    { isExclusive: 'desc' },
    { createdAt: 'desc' }
  ]
})
```

## The Root Cause: MISSING COMPOSITE INDEX

**Problem**: The Property table HAS an index on [clientId, source] and [clientId, isPublished],
but NO index on [clientId, operationType].

When filtering by operationType, PostgreSQL must:
1. Use the clientId index to narrow down to 1 client's records (good)
2. Then FULL TABLE SCAN on operationType within that client (SLOW!)

The 50-110ms DB query time is FAST, but the FRONTEND might be experiencing
slowness from:
- N+1 query issue with related records (images, driveFolders, shortUrls)
- Sorting by priority (which requires additional lookup)

## Missing Database Index

**File**: /root/web-apps/efesto/backend/prisma/schema.prisma
**Location**: Property model
**Current indexes**:
- @@index([clientId, source])
- @@index([clientId, isPublished])
- @@index([externalTokkoId])

**Missing**:
- @@index([clientId, operationType])
- @@index([clientId, operationType, isPublished]) <- EVEN BETTER

## Additional Slowness Factors

### Frontend Issues (Properties.jsx)
The fetchProperties() function includes ALL related data:
- 1x images include (filtered to take 1)
- 1x driveFolders include (no limit)
- 1x shortUrls include (filtered + limited)
- 1x _count for contents
- 3-way orderBy (priority, isExclusive, createdAt)

This causes Prisma to:
1. Fetch all matching Property records
2. Fetch related PropertyImage records for EACH property
3. Fetch related PropertyDriveFolder records for EACH property
4. Fetch related ShortUrl records for EACH property
5. Count Contents for EACH property
6. Sort in-app (no DB sort on priority/isExclusive)

This is FINE for small datasets (10-100 records) but becomes slow for:
- 1000+ properties
- Complex sorts requiring post-processing