Hi,
On a hunch I removed two (legacy) WHERE conditions from the following
query I obtained a 158x speed improvement. Yet these condiditions do not
filter anything. Does that make any sense?
The EXPLAIN ANALYSE output is attached with, first the fast version and
then the slow one.
I'd like to
On Wednesday 28 July 2010 12:27:44 Louis-David Mitterrand wrote:
The EXPLAIN ANALYSE output is attached with, first the fast version and
then the slow one.
I think you forgot to attach it.
Andres
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to
28.07.10 04:56, Tom Lane написав(ла):
I'm not asserting it's true, just suggesting it's entirely possible.
Other than the fork() cost itself and whatever authentication activity
there might be, practically all the startup cost of a new backend can be
seen as cache-populating activities. You'd
27.07.10 02:03, Lew написав(ла):
Piotr Gasidło wrote:
EXPLAIN ANALYZE SELECT ...
Total runtime: 4.782 ms
Time: 25,970 ms
Strangely, the runtime is shown with a period for the separator, though.
One value is calculated on server by EXPLAIN ANALYZE command, another is
calculated by psql
On Mon, Jul 26, 2010 at 01:47:14PM -0600, Scott Marlowe wrote:
Note that SSDs aren't usually real fast at large sequential writes
though, so it might be worth putting pg_xlog on a spinning pair in a
mirror and seeing how much, if any, the SSD drive speeds up when not
having to do pg_xlog.
xlog
On Mon, Jul 26, 2010 at 03:23:20PM -0600, Greg Spiegelberg wrote:
I know I'm talking development now but is there a case for a pg_xlog block
device to remove the file system overhead and guaranteeing your data is
written sequentially every time?
If you dedicate a partition to xlog, you already
Michael Stone wrote:
On Mon, Jul 26, 2010 at 03:23:20PM -0600, Greg Spiegelberg wrote:
I know I'm talking development now but is there a case for a pg_xlog
block
device to remove the file system overhead and guaranteeing your data is
written sequentially every time?
If you dedicate a
Yeb Havinga wrote:
Michael Stone wrote:
On Mon, Jul 26, 2010 at 03:23:20PM -0600, Greg Spiegelberg wrote:
I know I'm talking development now but is there a case for a pg_xlog
block
device to remove the file system overhead and guaranteeing your data is
written sequentially every time?
If
On 7/27/10 6:56 PM, Tom Lane wrote:
Yeah, if it weren't for that I'd say sure let's try it. But I'm
afraid we'd be introducing significant headaches in return for a gain
that's quite speculative.
Well, the *gain* isn't speculative. For example, I am once again
dealing with the issue that PG
On Wed, Jul 28, 2010 at 3:44 PM, Josh Berkus j...@agliodbs.com wrote:
On 7/27/10 6:56 PM, Tom Lane wrote:
Yeah, if it weren't for that I'd say sure let's try it. But I'm
afraid we'd be introducing significant headaches in return for a gain
that's quite speculative.
Well, the *gain* isn't
Robert Haas robertmh...@gmail.com writes:
However, if we don't support that, we can't do any sort of pooling-ish
thing without the ability to pass file descriptors between processes;
and Tom seems fairly convinced there's no portable way to do that.
Well, what it would come down to is: are we
On Wed, Jul 28, 2010 at 04:10:08PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
However, if we don't support that, we can't do any sort of pooling-ish
thing without the ability to pass file descriptors between processes;
and Tom seems fairly convinced there's no portable
Hi there,
I have a simple query where I don't understand the planner's choice to
use a particular index.
The main table looks like this:
# \d sq_ast_attr_val
Table public.sq_ast_attr_val
Column| Type | Modifiers
On Wed, Jul 28, 2010 at 9:18 AM, Yeb Havinga yebhavi...@gmail.com wrote:
Yeb Havinga wrote:
Due to the LBA remapping of the SSD, I'm not sure of putting files that
are sequentially written in a different partition (together with e.g.
tables) would make a difference: in the end the SSD will
On Wed, Jul 28, 2010 at 4:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
However, if we don't support that, we can't do any sort of pooling-ish
thing without the ability to pass file descriptors between processes;
and Tom seems fairly convinced there's no
Chris dmag...@gmail.com writes:
The query:
SELECT
assetid, custom_val
FROM
sq_ast_attr_val
WHERE
attrid IN (SELECT attrid FROM sq_ast_attr WHERE name =
'is_contextable' AND (type_code = 'metadata_field_select' OR
owning_type_code = 'metadata_field'))
AND contextid = 0
16 matches
Mail list logo
