Gauri Kanekar wrote:
> Is it possible to put Statement timeout at User Level.
> Like If i have a user like 'guest', Can i put a statement
> timeout for it.
If only all problems were that easily solved!
ALTER ROLE guest SET statement_timeout=1;
This will cause all statements longer than 10 s
On Tue, 29 Jan 2008, Gregory Stark wrote:
So, this is FYI, and also an added encouragement to implement fadvise
prefetching in some form or another. How's that going by the way?
I have a patch which implements it for the low hanging fruit of bitmap index
scans. it does it using an extra trip th
List,
I'm a bit confused as to why this query writes to the disk:
SELECT count(*)
FROMbigbigtable
WHERE customerid IN (SELECT customerid FROM
smallcustomertable)
AND x !=
'special'
AND y IS NULL
It writes a whole bunch of data to the disk that has the tablespace where
bigbigtable lives as we
>>> "Nikolas Everett" <[EMAIL PROTECTED]> wrote:
> I'm a bit confused as to why this query writes to the disk:
> SELECT count(*)
> FROMbigbigtable
> WHERE customerid IN (SELECT customerid FROM
> smallcustomertable)
> AND x !=
> 'special'
>
> AND y IS NULL
>
> It writes a whole bunch of dat
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> "Nikolas Everett" <[EMAIL PROTECTED]> wrote:
>> I'm a bit confused as to why this query writes to the disk:
> It's probably writing hint bits to improve performance of subsequent
> access to the table. The issue is discussed here:
> http://wiki.pos
How big is your work_mem setting, and is this behavior affected by its size?
You can increase the work_mem on an individual connection before the test.
Simply:
set work_mem = '100MB'
to set it to 100 Megabytes. If your issue is spilling data out of work_mem
to the temp storage, this setting wi
Under what conditions does EXPLAIN ANALYZE report spilling work_mem to
disk? When does it not report work_mem or other overflow to disk?
I know that a planned disk-sort shows up. I have also seen it report a
hash-agg on disk, but this was a while ago and rather difficult to reproduce
and I'm some
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> http://wiki.postgresql.org/wiki/Hint_Bits
On Thu, Sep 18, 2008 at 2:13 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> freezing old tuples
hash join was spilling out to temp files
>
Since this was a new table and the writes to the table's disk were very
"Scott Carey" <[EMAIL PROTECTED]> writes:
> Under what conditions does EXPLAIN ANALYZE report spilling work_mem to
> disk?
For hash joins, it doesn't. You might be thinking of the additional
reporting we added for sorts recently; but there's no comparable
logging for hash ...
On Thu, 18 Sep 2008, Matthew Wakeling wrote:
On Tue, 29 Jan 2008, Gregory Stark wrote:
I have a patch which implements it for the low hanging fruit of bitmap
index scans. it does it using an extra trip through the buffer manager
which is the least invasive approach but not necessarily the be
On Thu, Sep 18, 2008 at 1:30 PM, Greg Smith <[EMAIL PROTECTED]> wrote:
> If you have some specific bitmap index scan test case suggestions you can
> pass along (either publicly or in private to me, I can probably help
> anonymize them), that's one of the things that has been holding this up.
> Alte
I have two identical queries except for the date range. In the first case,
with the wider date range, the correct (I believe) index is used. In the
second case where the date range is smaller a different index is used and a
less efficient plan is chosen. In the second query the problem seems to be
12 matches
Mail list logo
