Sok Ann Yap wrote:
Kevin Grittner wrote:
Please show us your overall configuration and give a description
of the hardware (how many of what kind of cores, how much RAM,
what sort of storage system).
Here's the configuration (this is just a low end laptop):
version | PostgreSQL 9.0.4
Hi All,
I am a new comer on postgres world and now using it for some serious (at
least for me) projects. I have a need where I am running some analytical +
aggregate functions on data where ordering is done on Date type column.
From my initial read on documentation I believe internally a date
Dhimant Patel drp4...@gmail.com writes:
From my initial read on documentation I believe internally a date type is
represented by integer type of data. This makes me wonder would it make any
good to create additional column of Integer type and update it as data gets
added and use this integer
This makes me wonder would it make any good to create additional column of
Integer type and update it as data gets added and use this integer column for
all ordering purposes for my sqls - or should I not hasitate using Date type
straight into my sql for ordering?
Keep in mind what
Dhimant Patel drp4...@gmail.com wrote:
I am a new comer on postgres world and now using it for some
serious (at least for me) projects. I have a need where I am
running some analytical + aggregate functions on data where
ordering is done on Date type column.
From my initial read on
On Thu, Apr 28, 2011 at 12:17 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Dhimant Patel drp4...@gmail.com wrote:
I am a new comer on postgres world and now using it for some
serious (at least for me) projects. I have a need where I am
running some analytical + aggregate
Thanks for all valuable insights. I decided to drop the idea of adding
additional column and
will just rely on Date column for all ordering.
Tom - thanks for clear answer on the issue I was concerned about.
Maciek,Kevin -
thanks for ideas, hint on generate_series() - I will have to go through cpl
t...@fuzzy.cz wrote:
Anyway I'm not an expert in this field, but AFAIK something like this
already happens - btw that's the purpose of effective_cache_size.
effective_cache_size probably doesn't do as much as you suspect. It is
used for one of the computations for whether an index is small
Greg Smith g...@2ndquadrant.com wrote:
The reason no work can be done in this area is because there are
no standardized benchmarks of query execution in PostgreSQL being
run regularly right now. Bringing up ideas for changing the
computation is easy; proving that such a change is positive
On Fri, Apr 1, 2011 at 2:41 AM, Joseph Shraibman j...@selectacast.net wrote:
When I do a query on a table with child tables on certain queries pg
uses indexes and on others it doesn't. Why does this happen? For example:
[local]:playpen= explain analyze select * from vis where id 10747 ;
On Wed, Apr 27, 2011 at 10:27 PM, Robert Haas robertmh...@gmail.com wrote:
What if the user is using an SSD or ramdisk?
Admittedly, in many cases, we could probably get somewhat useful
numbers this way. But I think it would be pretty expensive.
gettimeofday() is one of the reasons why
On 04/27/2011 04:32 PM, Robert Haas wrote:
In the first case, PostgreSQL evidently thinks that using the indexes
will be slower than just ignoring them. You could find out whether
it's right by trying it with enable_seqscan=off.
My point is that this is just a problem with inherited tables.
Tomas Vondra wrote:
Hmmm, just wondering - what would be needed to build such 'workload
library'? Building it from scratch is not feasible IMHO, but I guess
people could provide their own scripts (as simple as 'set up a a bunch
of tables, fill it with data, run some queries') and there's a pile
Sok Ann Yap sok...@gmail.com wrote:
Anyway, the overhead of spawning 44 extra queries means that it is
still better off for me to stick with the original query and tune
PostgreSQL to choose index scan.
Maybe, but what is *best* for you is to tune PostgreSQL so that your
costs are accurately
On Wed, Apr 27, 2011 at 2:11 PM, Joseph Shraibman j...@selectacast.netwrote:
On 04/27/2011 04:32 PM, Robert Haas wrote:
In the first case, PostgreSQL evidently thinks that using the indexes
will be slower than just ignoring them. You could find out whether
it's right by trying it with
Joseph Shraibman wrote:
In a 52 gig table I have a select id from table limit 1 order
by id desc returns instantly, but as soon as you declare a child table
it tries to seq scan all the tables.
This is probably the limitation that's fixed in PostgreSQL 9.1 by this
commit (following a few
16 matches
Mail list logo
