Hello
HashSetOp is memory expensive operation, and should be problematic
when statistic estimation is bad.
Try to rewritre this query to JOIN
Regards
Pavel Stehule
2012/11/15 Antti Jokipii :
> Hi
>
> I tried to run quite simple query. For some reason query took lots of
> memory, more than 6GB.
On 15/11/12 15:03, Peter Geoghegan wrote:
On 15 November 2012 01:46, Andrew Dunstan wrote:
It cuts both ways. I have used CTEs a LOT precisely because this behaviour
lets me get better plans. Without that I'll be back to using the "offset 0"
hack.
Is the "OFFSET 0" hack really so bad? We've be
Hi
I tried to run quite simple query. For some reason query took lots of
memory, more than 6GB.
System start swapping, so I canceled it after 4 minutes. There were no
other queries in same time.
If I I understood my config correctly that is more than it should be. Is it
bug or is there some other
Postgres Performance Wizards,
I am a few years into developing and operating a system underpinned by
Postgres that sees the arrival a significant number of events around
the clock, not an epic amount of data, but enough to be challenging to
me, in particular when system downtime is not very palata
Can someone shed some light on the following query.
any help would certainly be appreciated!
thanks -
*
Maria Wilson
Nasa/Langley Research Center
Hampton, Virginia
m.l.wil...@nasa.gov
*
explain analyze
select a.ID, a.provider, a.hostname, a.username, a.eventTimeStamp,
a.AIPGUID, a.
Have a query using a CTE that is performing very poorly. The equivalent query
against the same data in an Oracle database runs in under 1 second, in Postgres
it takes 2000 seconds.
The smp_pkg.get_invoice_charges queries fedexinvoices for some data and
normalizes it into a SETOF some record ty
