David Blewett writes:
> Apparently there was a typo in the query that I didn't notice that
> excluded that table's columns. Here is the new output including it:
> http://pastesite.com/7017
Thanks. Could I trouble you for one other data point --- about how many
rows are in each of these tables?
Robert Haas wrote:
> Well, even if the table is not partitioned at all, I don't see that it
> should preclude parallel query access. If I've got a 1 GB table that
> needs to be sequentially scanned for rows meeting some restriction
> clause, and I have two CPUs and plenty of I/O bandwidth, ISTM i
Paolo Rizzi writes:
> Are you saying that PostgreSQL+PostGIS can actually run on a
> smartphone??? Intriguing...
> Did anyone ever actually tried that???
If it's a supported CPU type and you've got a suitable build toolchain,
sure. Seven or eight years ago we were getting a good laugh out of th
David Blewett writes:
> On Thu, May 7, 2009 at 6:44 PM, Tom Lane wrote:
>> Look into pg_stats for the rows concerning the columns used in the
>> query's WHERE and JOIN/ON clauses.
> Okay, here you go:
> http://rafb.net/p/20y8Oh72.html
I got some time to poke into this, but didn't get very far -
They didn't give me complete information, but it should be some kind
of industrial PC with a 600MHz CPU. Memory should be not huge nor
small, maybe a couple of GBytes, hard disk should be some type of
industrial Compact Flash of maybe 16 GBytes.
It should work perfectly OK.
Remember
They didn't give me complete information, but it should be some kind of
industrial PC with a 600MHz CPU. Memory should be not huge nor small,
maybe a couple of GBytes, hard disk should be some type of industrial
Compact Flash of maybe 16 GBytes.
It should work perfectly OK.
Reme
-Mensaje original-
De: Paolo Rizzi
Hi all,
recently I came across a question from a customer of mine,
asking me if it would feasible to run PostgreSQL along with
PostGIS on embedded hardware.
They didn't give me complete information, but it should be
some kind of industrial PC with
Robert Haas writes:
>> so I think that it is much easier for the database engine to efficiantly
>> search two 500G tables instead of one 1T table.
> And that leads me to the opposite conclusion on this point.
I don't think there would be any difference on that score, either.
>> IOW, I don't think you should need to partition if all you want is
>> load balancing. Partitioning should be for isolation, and load
>> balancing should happen when appropriate, whether there is
>> partitioning involved or not.
>
> actually, I will contridict myself slightly.
>
[...]
> however,
On 5/8/09 11:20 AM, "da...@lang.hm" wrote:
>
> with the Load Balancing Plan there is no benifit in partitioning unless
> you have the ability to run queries on each parition in parallel
>
I think there is a benefit to partitioning in this case. If the statistics
on other columns are highly sk
> -Mensaje original-
> De: Paolo Rizzi
>
> Hi all,
> recently I came across a question from a customer of mine,
> asking me if it would feasible to run PostgreSQL along with
> PostGIS on embedded hardware.
> They didn't give me complete information, but it should be
> some kind of in
On Fri, 8 May 2009, Robert Haas wrote:
On Thu, May 7, 2009 at 10:52 PM, wrote:
Hopefully, notions of partitioning won't be directly tied to chunking of
data for parallel query access. Most queries access recent data and
hence only a single partition (or stripe), so partitioning and
parallelis
Joshua D. Drake ha scritto:
On Fri, 2009-05-08 at 18:06 +0200, Paolo Rizzi wrote:
Hi all,
recently I came across a question from a customer of mine, asking me if
it would feasible to run PostgreSQL along with PostGIS on embedded hardware.
They didn't give me complete information, but it should
On 5/7/09 7:52 PM, "da...@lang.hm" wrote:
>
>
> I believe that the isolation plan is probably more common than the load
> balancing plan, but I don't see them as being that different for the
> database engine point of view. To tune a system that can handle the
> isolation plan for load balanci
On Fri, 2009-05-08 at 18:06 +0200, Paolo Rizzi wrote:
> Hi all,
> recently I came across a question from a customer of mine, asking me if
> it would feasible to run PostgreSQL along with PostGIS on embedded hardware.
> They didn't give me complete information, but it should be some kind of
> indu
On Thu, May 7, 2009 at 10:52 PM, wrote:
>>> Hopefully, notions of partitioning won't be directly tied to chunking of
>>> data for parallel query access. Most queries access recent data and
>>> hence only a single partition (or stripe), so partitioning and
>>> parallelism and frequently exactly or
Matthew Wakeling writes:
> Ah, now I see it - I re-analysed, and found entries in pg_stats where
> tablename is the name of the index. Now the query plans correctly and has
> the right estimates. So, one needs to analyse AFTER creating indexes -
> didn't know that.
Yes, for functional indexes
Hi all,
recently I came across a question from a customer of mine, asking me if
it would feasible to run PostgreSQL along with PostGIS on embedded hardware.
They didn't give me complete information, but it should be some kind of
industrial PC with a 600MHz CPU. Memory should be not huge nor smal
On Fri, 8 May 2009, Tom Lane wrote:
In this case, however, you evidently have an index on lower(distance)
which should have caused ANALYZE to gather stats on the values of that
functional expression. It looks like there might be something wrong
there --- can you look into pg_stats and see if the
Matthew Wakeling writes:
> When I wrap the fields in the constraints in a LOWER() function, the
> planner stops looking at the statistics and makes a wild guess, even
> though it is very obvious from just looking what the result should be.
Well, in general the planner can't assume anything abo
I'm running a rather complex query and noticed a peculiarity in the usage
of statistics that seriously affects the plan generated. I can extract the
relevant bit:
modmine-r9=# select * from pg_stats where tablename = 'geneflankingregion' AND
attname IN ('distance', 'direction');
schemaname
Hi Tom,
I should have looked at the analyzed plan first. The culprit for the
slow query were trigger function calls on foreign keys.
Ciao,
Viktor
Am 08.05.2009 um 01:06 schrieb Tom Lane:
Viktor Rosenfeld writes:
-> Seq Scan on corpus toplevel
(cost=0.00..1.39
22 matches
Mail list logo
