On Wed, Jan 28, 2009 at 11:37 PM, Scott Marlowe wrote:
> On Thu, Jan 29, 2009 at 12:01 AM, Kevin Traster wrote:
> > 2 questions:
> >
> > 1) Different costs for same actions. Doing an explain on 2 nearly
> identical
> > queries both involving the same Index scan on same table has 2 widely
> > diff
On Wed, Jan 28, 2009 at 11:37 PM, Scott Marlowe wrote:
> On Thu, Jan 29, 2009 at 12:01 AM, Kevin Traster wrote:
> > 2 questions:
> >
> > 1) Different costs for same actions. Doing an explain on 2 nearly
> identical
> > queries both involving the same Index scan on same table has 2 widely
> > diff
Kevin Traster writes:
> Regarding the previous posts about the same issues of PERFORMENCE between
> NOT IN versus EXCEPT. There has not been any answer to explain it - just
> talk about the differenences between the two results.
>
> Yes, I can still get the results using EXCEPT but it would be ni
Kevin Traster writes:
> Unique (cost=3506.21..303375872.86 rows=71946 width=8)
>-> Index Scan using cik_ciknum_idx on cik (cost=3506.21..303375616.75
> rows=102444 width=8)
> Filter: (NOT (subplan))
> SubPlan
>-> Materialize (cost=3506.21..6002.40 rows=18601
Hi,
If I have a view like:
create view X as (
select x from A
union all
select x from B)
and do
select max(x) from X
I get a plan like:
Aggregate
Append
Seq Scan on A
Seq Scan on B
If A and B are indexed on x, I can get the result much faster as:
select max(x) from (
selec
Is there a patch to make Wildspeed work with postgresql version 8.3.1?
P.S
My bad, the version number was incorrect in my previous mail.
-Original Message-
From: Oleg Bartunov [mailto:o...@sai.msu.su]
Sent: Wednesday, January 28, 2009 1:27 AM
To: Hari, Balaji
Cc: pgsql-performance@postgre
We won't need full text searching capabilities as in documents as the data type
is varchar.
Wildspeed will exactly fit our needs.
-Original Message-
From: Oleg Bartunov [mailto:o...@sai.msu.su]
Sent: Wednesday, January 28, 2009 1:27 AM
To: Hari, Balaji
Cc: pgsql-performance@postgresql.
On Thu, 29 Jan 2009, Hari, Balaji wrote:
Is there a patch to make Wildspeed work with postgresql version 8.3.1?
unfortunately, no.
P.S
My bad, the version number was incorrect in my previous mail.
-Original Message-
From: Oleg Bartunov [mailto:o...@sai.msu.su]
Sent: Wednesday, Janua
On Thu, Jan 29, 2009 at 10:58 AM, wrote:
> Hi,
>
> If I have a view like:
>
> create view X as (
> select x from A
> union all
> select x from B)
>
> and do
>
> select max(x) from X
>
> I get a plan like:
>
> Aggregate
> Append
> Seq Scan on A
> Seq Scan on B
>
> If A and B are indexed
Hi,When I try to restore a database dump on PostgreSQL 8.3 that's approximately
130GB in size and takes about 1 hour, I noticed index creation makes up the
bulk of that time. I'm using a very fast I/O subsystem (16 Mtron Pro 7535 SSDs
using a dual 1.2Ghz IOP/4GB cache RAID controller), fast CPU
Hi All,
I'm in the process of tuning a query that does a sort on a huge dataset.
With work_mem set to 2M, i see the sort operation spilling to disk
writing upto 430MB and then return the first 500 rows. Our query is of
the sort
select co1, col2... from table where col1 like 'aa%' order col1 lim
phoenix.ki...@gmail.com (Phoenix Kiula) writes:
> [Ppsted similar note to PG General but I suppose it's more appropriate
> in this list. Apologies for cross-posting.]
>
> Hi. Further to my bafflement with the "count(*)" queries as described
> in this thread:
>
> http://archives.postgresql.org/pgsql
On Thu, Jan 29, 2009 at 3:21 PM, henk de wit wrote:
> Hi,
> When I try to restore a database dump on PostgreSQL 8.3
> that's approximately 130GB in size and takes about 1 hour, I noticed index
> creation makes up the bulk of that time. I'm using a very fast I/O subsystem
> (16 Mtron Pro 7535 SSDs
On Thu, 2009-01-29 at 18:09 -0500, Robert Haas wrote:
> On Thu, Jan 29, 2009 at 3:21 PM, henk de wit wrote:
> > Hi,
> > When I try to restore a database dump on PostgreSQL 8.3
> > that's approximately 130GB in size and takes about 1 hour, I noticed index
> > creation makes up the bulk of that time
On Thu, Jan 29, 2009 at 3:15 PM, Subbiah Stalin-XCGF84
wrote:
> I'm in the process of tuning a query that does a sort on a huge dataset.
> With work_mem set to 2M, i see the sort operation spilling to disk writing
> upto 430MB and then return the first 500 rows. Our query is of the sort
>
> select
Robert Haas writes:
> On Thu, Jan 29, 2009 at 3:15 PM, Subbiah Stalin-XCGF84
> wrote:
>>
>> i see the sort operation spilling to disk writing upto 430MB and then
>> return the first 500 rows. Our query is of the sort
>>
>> Now if set the work_mem to 500MB (i did this in a psql session without
>>
Here you go.
Limit (cost=502843.44..502844.69 rows=501 width=618) (actual
time=561397.940..561429.242 rows=501 loops=1)
-> Sort (cost=502843.44..503923.48 rows=432014 width=618) (actual
time=561397.934..561429.062 rows=501 loops=1)
Sort Key: name
-> Seq Scan on objects (
Thanks Greg. You were right. If I set my sort_mem to 1G (yes I have
loads of memory, only for testing purpose), then I don't see any thing
written to disk. So in-memory require more memory than reported on-disk
storage.
Stalin
-Original Message-
From: Greg Stark [mailto:greg.st...@enter
Hi,> You can then> pull a TOC out with pg_restore and break that appart.
Reading the TOC is> pretty self evident. Once you get down to index creation
you can create> multiple files each with a group of indexes to create. Then
call> pg_restore multiple times in a script against the individual TO
"Joshua D. Drake" writes:
> On Thu, 2009-01-29 at 18:09 -0500, Robert Haas wrote:
>> Andrew Dunstan has been working on this problem. His latest parallel
>> restore patch can be found here:
>>
>> http://archives.postgresql.org/message-id/4977e070.6070...@dunslane.net
> Yeah but that isn't usefu
On Thu, Jan 29, 2009 at 1:56 PM, Chris Browne wrote:
>
> It is common for systems where it is necessary for aggregation
> reporting to be fast to do pre-computation of the aggregates, and that
> is in no way specific to PostgreSQL.
>
> If you need *really* fast aggregates, then it will be worthwhi
21 matches
Mail list logo
