Eddy Escardo-Raffo writes:
> For C, the planner estimated 10 thousand rows. For D, the planner estimated
> 100 thousand rows, yet for E the planner estimated only 1 row, which is the
> closest to reality. So, is there any way to specify a query that has a
> SUB-SELECT that returns a small set of v
Yeah, that was it. Thanks! I do have one more question at the bottom,
though, if anyone has enough time to read through my analysis
If I create the table as:
CREATE TABLE users
(
userid integer NOT NULL,
location integer NOT NULL,
CONSTRAINT pk_users PRIMARY KEY (userid)
)
WITH (
OIDS=FALSE
);
C
Thanks, Tom. I had discarded the possibility of data type mismatch already,
which was your first guess, but was wondering if the lopsided distribution
of location values would lead the planner to make a decision that is good on
average but bad for this particular query, as you point out in your sec
Eddy Escardo-Raffo writes:
> The table used in this query is called "users", and it has columns "userid"
> (primary key) and "location".
> The "location" column is indexed.
> The users table has 1 million rows, and all rows have integer typed value
> '-1' for "location" column, except for 2 rows
On Tue, 10 Nov 2009, Greg Smith wrote:
Laurent Laborde wrote:
It is on a separate array which does everything but tablespace (on a
separate array) and indexspace (another separate array).
On Linux, the types of writes done to the WAL volume (where writes are
constantly being flushed) require
Eddy Escardo-Raffo writes:
> Do you guys have any idea why this is not working as I expect?
Datatype issue maybe? When I try what seems to be the same case here
I get the expected indexscan, so I'm thinking the problem is that
the comparison isn't indexable, which is a possibility if the locatio
Hi, everyone.
Between postres docs, forum posts, previous similar questions answered and
random blogs, I've read as much as I could about why others have had similar
problems in the past before turning to you guys for help, so I really hope
this is not some completely obvious oversight on my part
Craig James wrote:
> I've wondered whether this would work for a read-mostly application: Buy
> a big RAM machine, like 64GB, with a crappy little single disk. Build
> the database, then make a really big RAM disk, big enough to hold the DB
> and the WAL. Then build a duplicate DB on another mach
I've wondered whether this would work for a read-mostly application: Buy a big
RAM machine, like 64GB, with a crappy little single disk. Build the database,
then make a really big RAM disk, big enough to hold the DB and the WAL. Then
build a duplicate DB on another machine with a decent disk
On Sun, 15 Nov 2009, Pavel Stehule wrote:
czech stemmer doesn't exist :(
I'd try morfessor http://www.cis.hut.fi/projects/morpho/, which is
unsupervised morphological dictionary. I think it'd be not very hard to add
morfessor dictionary template to tsearch2, so people could create their
ow
- Pg doesn't know the erase block sizes or positions. It can't group
writes up by erase block except by hoping that, within a given file,
writing in page order will get the blocks to the disk in roughly
erase-block order. So your write caching isn't going to do anywhere near
as good a job as the
On 15/11/2009 2:05 PM, Laszlo Nagy wrote:
>
>> A change has been written to the WAL and fsync()'d, so Pg knows it's hit
>> disk. It can now safely apply the change to the tables themselves, and
>> does so, calling fsync() to tell the drive containing the tables to
>> commit those changes to disk.
A change has been written to the WAL and fsync()'d, so Pg knows it's hit
disk. It can now safely apply the change to the tables themselves, and
does so, calling fsync() to tell the drive containing the tables to
commit those changes to disk.
The drive lies, returning success for the fsync when
2009/11/15 Oleg Bartunov :
> On Sun, 15 Nov 2009, Pavel Stehule wrote:
>
>> 2009/11/15 Oleg Bartunov :
>>>
>>> Yes, as stated original author use polish ispell dictionary.
>>> Ispell dictionary is slow to load first time. In real life it should be
>>> no
>>> problem.
>>>
>>
>> it is a problem. Peop
On Sun, 15 Nov 2009, Pavel Stehule wrote:
2009/11/15 Oleg Bartunov :
Yes, as stated original author use polish ispell dictionary.
Ispell dictionary is slow to load first time. In real life it should be no
problem.
it is a problem. People who needs fast access uses english without
czech. It d
On 15/11/2009 11:57 AM, Laszlo Nagy wrote:
> Ok, I'm getting confused here. There is the WAL, which is written
> sequentially. If the WAL is not corrupted, then it can be replayed on
> next database startup. Please somebody enlighten me! In my mind, fsync
> is only needed for the WAL. If I could c
16 matches
Mail list logo
