On Tue, 17 Feb 2009, Rajesh Kumar Mallah wrote:
sda6 --> xfs with default formatting options.
sda7 --> mkfs.xfs -f -d sunit=128,swidth=512 /dev/sda7
sda8 --> ext3 (default)
it looks like mkfs.xfs options sunit=128 and swidth=512 did not improve
io throughtput as such in bonnie++ tests .
it
Hi,
Let's say I have a table (tbl) with two columns: id1, id2.
I have an index on (id1,id2)
And I would like to query the (12;34) - (56;78) range (so it also may
contain (12;58), (13;10), (40;80) etc.). With the index this can be done
quite efficiently in theory, but I cannot find a way to make th
On Tue, 17 Feb 2009, Havasvölgyi Ottó wrote:
I created a big enough table (131072 records, and it had also a 3rd
field with about 120 character text data). But Postgres performs a
SeqScan.
Firstly, you should always post EXPLAIN ANALYSE results when asking about
a planning problem.
Secondly
Havasvölgyi Ottó writes:
> I also tried Row constructors with a Between expression, but in this case
> Postgres handled the elements of the row independently, and this led to
> false query result.
What version of Postgres is this? row constructors were fixed a long time ago
to not do that and t
On Tue, Feb 17, 2009 at 5:15 PM, Matthew Wakeling wrote:
> On Tue, 17 Feb 2009, Rajesh Kumar Mallah wrote:
>>
>> sda6 --> xfs with default formatting options.
>> sda7 --> mkfs.xfs -f -d sunit=128,swidth=512 /dev/sda7
>> sda8 --> ext3 (default)
>>
>> it looks like mkfs.xfs options sunit=128 and
Hi,
I have a query SELECT * FROM myTable WHERE ((myCol = var1) OR (myCol =
var2))
.. which produces the following EXLAIN output:
Index Scan using myIndex on myTable (cost=0.00..8.28 rows=1 width=537)
Filter: ((myCol = $1) OR (myCol = $2))
The index "myIndex" is an index on column "myCol"
Gregory Stark writes:
> Havasvölgyi Ottó writes:
>> I also tried Row constructors with a Between expression, but in this case
>> Postgres handled the elements of the row independently, and this led to
>> false query result.
> What version of Postgres is this? row constructors were fixed a long t
>>> Havasvölgyi Ottó wrote:
> WHERE (id1>12 or id1=12 and id2>=34)
> and (id1<56 or id1=56 and id2<=78)
As others have pointed out, if you are using 8.2 or later, you should
write this as:
WHERE (id1, id2) >= (12, 34) and (id1, id2) <= (56, 78)
On earlier versions you might want to try
Hi,
I have table containing bytea and text columns. It is my storage for
image files and it's labels. Labels can be 'original' and 'thumbnail'.
I've C-function defined in *.so library and corresponding declaration in
postgres for scaling image. This function scale image and insert it into
the same
Generally speaking, you will want to use a partition that is 25% or less the
size of the whole disk as well. If it is the whole thing, one file system can
place the file you are testing in a very different place on disk and skew
results as well.
My own tests, using the first 20% of an array fo
On Tue, Feb 17, 2009 at 11:17 AM, Alexander Gorban
wrote:
> Hi,
>
> I have table containing bytea and text columns. It is my storage for
> image files and it's labels. Labels can be 'original' and 'thumbnail'.
> I've C-function defined in *.so library and corresponding declaration in
> postgres fo
On Mon, Feb 16, 2009 at 11:04 PM, Ross J. Reedstrom wrote:
> Recently I've been working on improving the performance of a system that
> delivers files stored in postgresql as bytea data. I was surprised at
> just how much a penalty I find moving from a domain socket connection to
> a TCP connectio
Thanks, it's a very good idea!
Otto
2009/2/17 Kevin Grittner
> >>> Havasvölgyi Ottó wrote:
>
> > WHERE (id1>12 or id1=12 and id2>=34)
> > and (id1<56 or id1=56 and id2<=78)
>
> As others have pointed out, if you are using 8.2 or later, you should
> write this as:
>
> WHERE (id1, id2) >= (12,
On Tue, Feb 17, 2009 at 12:46 PM, Alexander Gorban
wrote:
> В Втр, 17/02/2009 в 12:24 -0500, Robert Haas пишет:
>> On Tue, Feb 17, 2009 at 11:17 AM, Alexander Gorban
>> wrote:
>> > Hi,
>> >
>> > I have table containing bytea and text columns. It is my storage for
>> > image files and it's labels.
On Tue, Feb 17, 2009 at 12:20:02AM -0700, Rusty Conover wrote:
>
>
> Try running tests with ttcp to eliminate any PostgreSQL overhead and
> find out the real bandwidth between the two machines. If its results
> are also slow, you know the problem is TCP related and not PostgreSQL
> related
В Втр, 17/02/2009 в 12:24 -0500, Robert Haas пишет:
> On Tue, Feb 17, 2009 at 11:17 AM, Alexander Gorban
> wrote:
> > Hi,
> >
> > I have table containing bytea and text columns. It is my storage for
> > image files and it's labels. Labels can be 'original' and 'thumbnail'.
> > I've C-function defi
On Feb 17, 2009, at 1:04 PM, Ross J. Reedstrom wrote:
On Tue, Feb 17, 2009 at 12:20:02AM -0700, Rusty Conover wrote:
Try running tests with ttcp to eliminate any PostgreSQL overhead and
find out the real bandwidth between the two machines. If its results
are also slow, you know the problem
On Tue, Feb 17, 2009 at 01:59:55PM -0700, Rusty Conover wrote:
>
> On Feb 17, 2009, at 1:04 PM, Ross J. Reedstrom wrote:
>
>
> What is the client software you're using? libpq?
>
python w/ psycopg (or psycopg2), which wraps libpq. Same results w/
either version.
I think I'll try network sniff
On Tue, Feb 17, 2009 at 03:14:55PM -0600, Ross J. Reedstrom wrote:
> On Tue, Feb 17, 2009 at 01:59:55PM -0700, Rusty Conover wrote:
> >
> > What is the client software you're using? libpq?
> >
>
> python w/ psycopg (or psycopg2), which wraps libpq. Same results w/
> either version.
>
It's not
On Tue, Feb 17, 2009 at 2:30 PM, Ross J. Reedstrom wrote:
> On Tue, Feb 17, 2009 at 03:14:55PM -0600, Ross J. Reedstrom wrote:
>> On Tue, Feb 17, 2009 at 01:59:55PM -0700, Rusty Conover wrote:
>> >
>> > What is the client software you're using? libpq?
>> >
>>
>> python w/ psycopg (or psycopg2), w
I do no, but you really need rescale the image when he comes to database? or
can you doing this after, in a schudeled job?
If you need resize the image en it comes, I believe you pay a price related
about performance because the this is working to save image, the toast
strtucture are receiving the
the raid10 voulme was benchmarked again
taking in consideration above points
# fdisk -l /dev/sda
Disk /dev/sda: 290.9 GB, 290984034304 bytes
255 heads, 63 sectors/track, 35376 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
Detailed bonnie++ figures.
http://98.129.214.99/bonnie/report.html
On Wed, Feb 18, 2009 at 1:22 PM, Rajesh Kumar Mallah
wrote:
> the raid10 voulme was benchmarked again
> taking in consideration above points
>
> # fdisk -l /dev/sda
> Disk /dev/sda: 290.9 GB, 290984034304 bytes
> 255 heads, 63
23 matches
Mail list logo
