Bryce Nesbitt skrev:
> I've got a legacy app with a hefty performance problem. The basic
> problem is stupid design. It takes 10-15 seconds of CPU time to look up
> an invoice.
> Basically it's trying to mash up extra columns on an otherwise simple
> query, and those extra columns are subtotals.
=?UTF-8?B?TmlzIErDuHJnZW5zZW4=?= <[EMAIL PROTECTED]> writes:
> Bryce Nesbitt skrev:
>> I've got a legacy app with a hefty performance problem.
> It is not clear whether there is a FK relation between eg_order and
> eg_order_line and what the PK of eg_order is.
Or in English: can there really be m
Great analysis Gregory & Tom... UNION ALL will make a difference.
---
Here invoices consist of orders, orders consist of order lines. Thus,
each order_id corresponds to just one invoice_id.
One possibility is to add an invoice_i
Mohd Ghalib Akhtar wrote:
> how to download linux 7.3 image file(means os) ?
>
It is not clear to me what you are trying to do. If you wish to download the
.iso files for Red Hat Linux 7.3, it has nothing to do with this mailing list.
Furthermore, RHL 7.3 has been discontinued for several years an
Tom Lane skrev:
>> PG apparently is not smart enough to recognize that the
>> result of a max must be one of the values of the column (meaning that it
>> can use an index)
>
> That's because it can't. As written, the query demands sums over groups
> that *include* a specific invoice_id --- but e
Nis Jørgensen <[EMAIL PROTECTED]> writes:
> Well, the query can be satisfied by looking only at the rows with an
> order_id matching the invoice_id given. The condition that this is the
> largest invoice in the group then needs to be checked afterwards.
>
> I certainly did not expect the query pla
Gregory Stark skrev:
> Nis Jørgensen <[EMAIL PROTECTED]> writes:
>
>> Well, the query can be satisfied by looking only at the rows with an
>> order_id matching the invoice_id given. The condition that this is the
>> largest invoice in the group then needs to be checked afterwards.
>>
>> I certainl
